The Bottleneck Moves Again

Sometime in the early part of 2026, I started keeping a small spreadsheet that I did not show anyone outside the studio for about four months. It had two columns for each project we had shipped since the beginning of 2024. The first column was the number of weeks between the first client conversation and the first deployed build that a paying customer could, in principle, use. The second column was the number of months between that deployed build and the first customer who actually paid for it. I had expected, when I started the sheet, to see both numbers fall. That was the story I had been telling in talks and on podcasts for most of the previous year, and I wanted to see it in our own data before I kept telling it.

Only one of the columns fell.

The first column collapsed in a way I have not seen any other metric in this studio collapse in seventeen years. A founder-facing CRM that would have taken us twelve weeks to get to a shippable state in early 2024 took six weeks by the middle of that year and three weeks by the autumn of 2025. A niche marketplace for a client in Osaka, which on the old scoping-to-deployment curve would have been a four-month engagement, shipped in nineteen working days. An internal tool for a logistics operator in Rotterdam, which we priced as a ten-week project out of habit, was in their staging environment in fourteen working days. I am rounding, and I am deliberately picking the projects where the effect was most visible, but the collapse is on the spreadsheet, across thirty-odd rows of it. The first column is a waterfall, in the wrong sense of the word.

The second column is flat.

That is the observation the rest of this Part has to answer for. Time-to-shippable has fallen by roughly a factor of four in two years. Time-to-first-paying-customer has not moved. In a couple of cases it has gone the other way; one client who would, on the old cadence, have had paying users inside ninety days of handover took closer to seven months to find his first five, and he shipped a better product than any of the ones that preceded him. The two lines used to track each other. A faster build meant a faster first sale, because the bottleneck was the build. The lines have now come apart, and the gap between them is widening every quarter.

We have watched this happen twice in eighteen months, and I am no longer prepared to call it noise.

Every methodology I have worked under has been an answer to a specific question about what was slowest, and every methodology has, in solving its question, exposed the next one. This is the ordinary pattern of problem-solving in any field with more than one constraint. You move the tight bolt; the frame flexes somewhere else. What is useful is naming the bolts in order, because it tells you what the current one actually is.

Waterfall was an answer to chaos. Before it, software work in most shops was a verbal tradition held in the heads of three or four senior people, and the thing that killed projects was nobody agreeing on what was being built. Royce’s 1970 paper, which is usually read as a manifesto for the approach, reads in its own voice as a warning against it; he describes the sequential model and then, almost in the next breath, says it is risky and invites failure.¹ The industry needed the chaos-to-order move so badly that it took the model and ignored the warning. Waterfall solved chaos. It exposed rigidity. Once you had written the specification down, you were trapped inside it, and by the time the specification was wrong — which it always was, because the world it described had already moved — you had spent a year building against it.

Agile was an answer to rigidity. The Snowbird manifesto in 2001 is a short document, and most of it is about loosening the grip of specification on the working day.² Iterate. Ship small. Talk to the customer. The word that keeps recurring in the secondary literature is responsive, which is exactly the right word; agile made teams responsive in a way waterfall teams structurally could not be. Agile solved rigidity. It exposed ceremony. By the second half of the 2010s, being agile meant, in most of the Fortune 500 offices I walked through, running a standup at 9:15, a retro on Friday, a sprint review every second Thursday and a quarterly PI planning session with laminated cards on a wall the size of a tennis court. The ceremony was what happened when a method survived past the problem it was invented for.

Sculpting is an answer to the prototype gap — the months of extraction, translation and scoping that used to sit between a founder having an idea and the team having something to build against. If you have read this far in the book, you have heard me describe that gap more than once, because for fifteen years it was the commercial bedrock of this studio. The gap has closed. The tools that closed it are not yet two years old in any mature form, and they are not stable, and they are not doing it cleanly, but they are doing it. A founder now arrives with a working repository, not a napkin. We do not scope; we sculpt. Sculpting solves the prototype gap. It exposes the thing the prototype gap had been hiding from us, which is that shipping a product and selling a product were never the same problem, and the old methodology let us treat them as if they were because the first one was so much more expensive than the second that the second one was rounding error.

The two-column spreadsheet is the clue. If you can get from first conversation to shippable build in three weeks, and it still takes you six or seven months to find the first handful of paying customers, then the expensive part of your business has moved away from the build. The build is a Tuesday. The expensive part is every line item that used to be cheap because the build cost more: positioning, launch, audience, trust, the long slow work of being heard. All of that was always there, and all of it always cost something, but when a product took nine months to ship and three months to sell, the sell was a quarter of the problem. When a product takes three weeks to ship and six months to sell, the sell is eighty-five per cent of the problem.

This is the point the industry around us is starting to name, in its own vocabulary, at its own pace. Alenezi’s 2026 paper on verification is the clearest single piece of writing I have seen on the next bolt along — his argument, paraphrased, is that as generation speeds up, the scarce resource becomes the humans and systems that can confirm the generated thing is correct and safe to deploy.³ He is writing about code specifically, and his evidence is a review of twenty-three studies, preprints and expert surveys rather than fieldwork of his own, but I think the claim generalises. The bottleneck moves to whatever step the accelerated step has left standing. For him, that step is verification. For us, in the portfolio numbers I have been watching, it is distribution. The two are cousins. Both are answers to the same structural question, which is: what is now the slowest part of getting a new thing from an empowered individual to the people who should be using it?

I want to be careful here, because this is the kind of claim that can be made to sound more sweeping than it is. I am not saying every business has become a marketing business. I am not saying the craft of building has ceased to matter; if anything, this whole book has been an argument that the craft now carries more of the weight, because the subtraction pass is harder than the assembly one. What I am saying is narrower. For the kinds of software projects Sliday takes on — small-to-mid-sized products built for founders and studio-owner clients who want a thing to exist in the world — the constraint has moved from the left-hand side of the value chain to the right-hand side. Any empowered founder who can describe what they want, plus any competent studio that can sculpt and harden what the tools generate, can put a polished product in the market in eight weeks. Some of ours have done it in five. The scarce thing now is the audience that will care.

We built the tools that collapsed the first column because the first column was hard to look at for fifteen years, and we wanted it to stop being hard. The equivalent tools for the second column do not yet exist, and the spreadsheet is on my desk at the end of every week to remind me that they do not. The first column is not climbing back. The second column is not falling of its own accord. The gap between them is the work.

Shipping got cheaper; selling did not.