A solo founder can now run several AI builders at once, and the first thing I learned is that extra builders speed up nothing if every question and every handoff still ends at my desk. Each builder needs enough context to do useful work and each result needs someone to evaluate it, so when all of that runs through me, more execution capacity just becomes a longer line. I’m building Tapestry to find out how fast one founder can build, test and learn once that line is gone, because the time it frees is what enables me to spend my days with the users who will decide whether the product is worth paying for.
I have built and scaled companies several times, including Leverage AI, which was acquired earlier this year, and the bottleneck was often me, even when I had more people and more money behind me.
Tapestry is built around a relationship problem, which is that useful context can sit in years of conversations and still be missing when you need it. The product is local first, with people choosing the sources they connect, so decisions about what the software can use and how it behaves are central to making it useful.
In The Agent Stack Is the New OS, I argued that the value of these tools comes from how an operator organizes the work around them, and Tapestry is where I’m putting that idea into practice. I use a technical program manager, an AI agent I call the TPM, to turn my direction into scoped work for several AI builders and to decide what comes back to me. Steve Yegge’s Gas Town explores the same problem from the tooling side, and what I’m working on here is the structure of authority around the builders.
The TPM owns the return path
I set the product direction and make the consequential tradeoffs, and Claude acts as the TPM, turning that direction into scoped work and coordinating the coding agents assigned to it. The builders are Claude Code sessions running in the cloud, Linear holds the scoped issues and decisions, and GitHub holds the implementation and its checks, which is what lets a fresh session pick up from the latest recorded decision without anyone reconstructing the last conversation.
An assignment explains the intended behavior, how the result will be checked and what the builder is allowed to change. Within that grant, builders evaluate their own work and merge routine changes once the current version passes the required checks, and the TPM audits the results afterward and sends work back when it falls short. If every routine merge had to wait for the TPM, the bottleneck would simply move from my desk to the TPM’s, so the assignment and the checks have to carry enough authority for ordinary work to proceed.
When a builder reaches a decision outside its scope, it stops that part of the work and returns a specific question with a recommendation, which the TPM answers within its delegation or brings to me, and my answer goes back into the issue where the next session can act on it. I keep control of production, spending and release, and permission to merge a feature doesn’t by itself authorize putting it in front of members.
Independent work moves forward while the TPM brings me only the decisions that need my judgment.
Parallel work needs boundaries
Several builders can work on independent pieces at the same time, each with its own assignment and branch, and the TPM has to find where those pieces overlap and sequence the work that shares a dependency. In one stretch of the records, two builders’ work touched the same settings surface, so the TPM held one assignment until the other change merged while everything else kept moving. Adding builders helps only when there are ready, independent assignments to give them, which puts the weight on the quality of the assignment and on my deciding which work matters.
Case study: one report, twenty hours
Manny Cerniglia, co-founder of Flyhound and one of our early beta testers, emailed me to say Tapestry kept asking him to connect WhatsApp, which he does not have installed. Within five minutes I had told a session to take it, a builder merged the fix a little under four hours after his email, and the release that carried it was available about twenty and a half hours after his email. I approved the release cut and the note telling him it was live, and a session sent that note eighteen minutes after the release.
One tester report from email to published fix, shown as elapsed time from the records.
That is one fix. The same records cover 28 fixes from eight early testers over the past month, and they show where I sit. I took in and decided on every one of them. At the median, my decision came an hour and a half after the feedback arrived, sessions and builders merged the work about three hours and forty minutes after that, and the release followed about six hours and forty minutes later. After deciding, I took three actions per fix, mostly approvals, answers to a builder’s question and starting a session, and nine when I count the steps of cutting the release that carried it.
This is the division of labor I am after. I stay at both ends, taking in what users say and deciding what gets built, and most of the middle runs without me.
Where the bottleneck moves next
Taking myself out of the handoffs moves the bottleneck downstream, to verification, release and the handoff into marketing, and I think each needs the same treatment. Every added builder creates work that has to be checked, so draft PRs run a smaller set of checks, the full required suite runs when a change is ready for review, and any later change needs fresh validation before it can merge. Releases follow the same pattern, where I approve a version or a standing grant and the release tooling does the rest of the build and submission, and the desktop, iPhone and browser extension details are in Tapestry’s own write-up.
What the speed is for
For a founder, the build-test-learn loop at the heart of the lean startup approach is limited by how many things can be built at once and how long a piece of feedback takes to become a shipped change. With a TPM scoping the work and builders merging within delegated authority, what a user tells me can become a scoped assignment and a merged change in hours, without me writing the code, so I can ship a minimum version, put it in front of users and act on what they say at a pace that used to need a large team. That is why I care about the bottleneck, since every hour I am not routing questions is an hour with the users who decide what gets built next and whether it is something they will pay for.
What the record shows
In the repository records for the weeks since I started adding builders, merged pull requests rose from 284 in the week of October 12 to 409 in the week of November 2, and the more telling change is who wrote them: Claude Code sessions that I or the TPM started from my own account produced 262 of those 284 and 49 of the 409, with the rest coming from named builders working under the TPM. Output went up by about 44% while the share written from my own account fell from 92% to 12%. The figures here come from Linear, GitHub, release records, my own Claude Code session logs and my email, and the mechanics behind them are in Tapestry’s write-up.
However, speed per change did not improve. The median time from first commit to merge went from about 0.8 hours when a single builder was working alone to about 3.2 hours in the four-builder week, and I think more review and checks per change account for the lion’s share. Quality held up, with no reverted merges among 1,254 merges to the main branch between October 19 and November 11, and 66 of 486 builder pull requests (13.6%) needing another commit after being marked ready for review.
What’s most impactful here is the continuity. Since October 29 the longest gap between any two builder merges has been 3.4 hours, and in overnight stretches of 11 to 12 hours when I wasn’t writing in the project threads, builders merged as many as 28 pull requests.
What I haven’t established
Builders did not run fully in parallel, because usage limits on the AI platform make cost one of the main limits on speed. Managing those limits is a constant part of the job, and days with three or more builders merging were rare, three in the week of November 2 and three more through November 11. I think what it costs to add a builder matters as much to the economics as the workflow does, and it is the lever I watch most closely. The longest stretch I can document without writing in the project threads is about twelve hours overnight, so I’m not claiming multi-day unattended operation, and I’m still counting how many decisions reached me.
A merge count says little about how hard the changes were or whether the product became more useful to members, and the 100× founder idea is a design ambition I’m testing, with the open question being whether independent work keeps scaling without each added builder creating a matching coordination burden.
In Superhuman, Not Smaller, I argued for giving people more capability while keeping their judgment and institutional knowledge, and Tapestry is where I’m testing that as a founder. The test I hold each added builder to is whether the product reaches users faster while more of my time goes to those users. If the line at my desk gets longer, I have added coordination work in place of capacity, and if it stays short, one founder can build and learn at the pace of a much larger team. The measure I care about is how much of my week goes to talking with the people who will pay for this.
Companion article: How we build Tapestry. Explore the workflow and request a private walkthrough.