How It Fails

The founder I want to tell you about is forty-two years old, a solo product lead who had spent the previous fourteen years inside a mid-sized logistics company in Melbourne, and she arrived in our inbox on a Tuesday in March last year with a working prototype of a scheduling tool for small dental practices. She had built it across six weekends. It ran. It had an onboarding flow, a calendar view and a patient-reminder pipeline that hit an SMS gateway she had wired herself.

At the top of the home screen, occupying more pixels than any other element, sat a custom rich-text editor for practice notes, with a formatting toolbar she had drawn in Figma and re-implemented three times because she could not get the tab behaviour right. She called me on Thursday. She wanted us to take it the rest of the way. She was articulate, she had money, she had done her homework and by the end of the first call she had used the word love about the editor twice.

We took the engagement. Six months later we handed back a product that was live, paying and growing at a rate the founder described in her next raise as better than plan. Between those two dates the engagement almost collapsed three times, each time for a different reason, and each reason is the subject of this chapter. I will call her Priya here: a composite drawn from four engagements between 2024 and 2026, with the stack, timeline and resolution adjusted to anonymise.

The first collapse was the editor.

Our first deletion sprint, in the first week of the engagement, had the editor in the cut column. The dental practices Priya had interviewed (fifteen of them, a genuinely larger sample than most founders arrive with) did not use the formatting toolbar. They typed notes in plain text and pressed enter. The feature cost us a rendering bug on Safari, a mobile selection bug on iOS and a test suite that was longer than the rest of the application combined. Our Sculptor drafted the rationale, two sentences, and put it in the document. Priya read the document on Thursday evening, and on Friday morning asked for a call.

The call went for ninety minutes. She had arguments, and some of them were good. The editor was what made the product feel considered rather than generic. She had spent time on it. A practice manager in one of her interviews had said the phrase nice touch about the toolbar, and she had shown it to three people who all called it impressive. By the end of the ninety minutes she had not talked us out of the cut, but she had extracted a promise that the deletion would be revisited in a month, and she had been crying for the last fifteen minutes of the call and was apologising for it, which is the part I will not forget.

This is the first failure mode, and it is the one that will hurt you most often. Founders who have built a prototype cannot let go of the features they built. It is the structural condition of having built the thing. I have made the same mistake twice in my own products. The IKEA Effect, Industrialised named the mechanism: generative tools that let a founder spend a weekend on a feature nobody asked for and then own it in a way no amount of research can dislodge. The Discipline of Subtraction named the discipline: editorial work, paid for, ritualised. This chapter names what happens when the discipline meets a founder who is not yet ready for it.

The counter-move we have settled on, and the one I would recommend to any studio starting out in this work, is contractual. The deletion criteria go into the master services agreement. Not as an annex, not as a schedule, not as a clause the founder reads once and forgets: in the body of the contract, at signing, read aloud, initialled line by line.

Ours reads roughly like this. Any feature used by fewer than an agreed percentage of active users after a specified number of weeks is a candidate for deletion. Any feature whose test-suite cost exceeds an agreed share of the engineering budget is a candidate. Any feature the studio and the founder cannot jointly justify in a paragraph, on request, is a candidate. The percentages are negotiated for the specific engagement; the criteria are not. An illustrative agreement might use 10 per cent usage over eight weeks and a test-suite ceiling of 15 per cent of engineering cost. Those numbers are examples, not a studio default; choose thresholds from the product’s economics and write them down before the review.

The criteria are rehearsed at the first deletion sprint. We walk the founder through the document she signed, and we apply the criteria to one of her own features in front of her, which is a deliberate kindness because the alternative is to apply them to all of her features at once later.

Priya’s editor was run against the criteria. It failed every one of them. We cut it in week five, after the second deletion sprint, and she was cross for a fortnight and then, in a standup in week eight, said unprompted that she had not missed it. That sentence is why we rehearse the criteria at the first sprint, and not at the third.

The contractual criteria are necessary, but they do not cover a product the client keeps reopening after approval. David Kravitz describes this problem on a health-platform engagement. His counter-move was to agree a launch date, collect real usage data, clear the invoice and refine from that evidence. The lesson is to agree when review ends and learning from use begins.

The second collapse was the stack.

Priya’s prototype, like most prototypes we receive, was built on the fastest path a founder can take to a working demo. Firebase for authentication, because the tutorial she had followed used Firebase. SQLite for the database, which is the default the generator had suggested and which she had not thought to change. No rate limiting anywhere. A public endpoint that returned the full patient record on an unauthenticated GET, because she had been testing it in Postman and forgotten to lock it afterwards. Secrets in a config file committed to the repository history. A single API key, hardcoded, shared by every instance.

None of this is incompetence. It is the normal condition of a weekend prototype, and every founder we have worked with in the last eighteen months has arrived with some variant of it. The tutorial culture optimises for the demo video. The demo video does not show the auth flow, because the auth flow is boring. The founder ships what the tutorial showed.

The empirical case for taking this seriously is sharper than any we could construct ourselves. Borg, Tornhill and colleagues, in a study that appeared as a preprint in January and was peer-reviewed by April, found model refactorings failing markedly more often on the weakest-health files.¹ They did not look at weekend prototypes; the founder repositories we audit are made of files in that band, which is our count and not theirs. The 2024 DORA report pointed the same way from a different angle, reporting that each modelled 25 per cent rise in AI adoption came alongside a 7.2 per cent drop in delivery stability and a 1.5 per cent drop in throughput across its respondents.² Two separate findings, from two unrelated methods, neither of which measured the other. I read them as pointing at the same place. That reading is mine.

A studio that accepts Priya’s prototype and begins adding features without hardening takes on a risk these studies make easier to see, though neither of them measured what a weekend prototype does once it is carrying real users. The methodology rewards the feeling of speed. The ledger records the cost.

Our counter-move is a milestone, priced and named: the production readiness gate from From Builders to Hardeners. It sits between the prototype handover and any feature work, it is quoted separately, it is paid separately and it is not optional. The deliverable is that chapter’s hardening checklist walked through line by line against the received codebase: auth audited, database chosen for the production load envelope, rate limiting, secrets, input validation, observability, a rehearsed rollback. The gate has a name because it has to be invoiceable; a line item a founder can see and accept is a line item a founder will not later dispute.

Priya fought this one for a week, because it delayed the feature she cared about by three weeks and cost her a named figure she had not budgeted for. We held. We have held on the production readiness gate in every engagement since we introduced it, and we have lost precisely one deal over it, which is the price of the discipline. The deal we lost was a founder who wanted to skip the gate and ship; six months later we saw his product on Hacker News with a post-incident write-up that mentioned, among other things, an unrotated API key.

The third failure mode is the one the studio will do to itself.

About four months into Priya’s engagement, in the middle of a standup, our project lead said the words let’s scope it properly, and nobody noticed. He meant, and the team heard, the old thing. A two-week discovery. A thirty-page document. Acceptance criteria per screen. User stories in Jira, with point estimates per story. The room agreed. By the end of the day a Google Doc titled Priya — Phase 2 Scope, Draft 1 had fourteen pages in it and the first three acceptance criteria for a feature Priya had not actually asked for. We were three days into writing the document before the Sculptor on the project read the draft, put it down, and asked whether we had forgotten what we were selling.

We had. Not catastrophically, and not for long, but we had. Old muscle memory fires whenever the new method gets hard, and the method is hardest precisely when it is working: when the prototype is in front of you, the founder is emotional, the deletion sprint is a week away, and the thing you know how to do from the last fifteen years is not the thing the moment calls for. The temptation to reach for a thirty-page scope is a failure of habit. And if the studio does not have a ritual for catching the habit, the habit wins.

Our counter-move here is a semi-annual process audit, which we call the Reversion Log. A studio member who was not on the project reads the last three engagements end to end and names, without criticism, every place the team reverted to old-style scoping. Where did a deletion sprint become a meeting. Where did a production readiness gate become a sentence in an email. Where did a one-paragraph justification become a Confluence page. The list is read aloud at the next all-hands, because process drift is invisible to the people doing the drifting.

Our first audit, which I wrote myself in September of last year, named 23 reversions across three engagements. Our most recent one named six. The number is a thermostat, not a score. The aim is to catch the drift early enough to correct it on the next engagement.

A word to the founder reading this chapter. The methodology will only fail on you if it is allowed to. You are entitled to ask, at the first call, whether the studio’s contract carries a deletion clause and whether the production readiness gate is priced on the proposal. If neither is true, the engagement is still agile with new tools on top, and the failure modes of agile (ceremony, scope creep, invoices larger than the product) will be the ones you end up paying for. A founder who has read to this point in the book has done the homework. Bring the questions into the sales call.

We have made two of these three mistakes ourselves: indulged a founder because she was charming and the feature was clever and the invoice was large, and reverted to thirty-page scoping because it was Thursday and the founder wanted a document we knew how to write. The third — shipping a prototype without hardening — we have avoided so far, and I am superstitious enough not to claim we always will. Naming the failure modes does not prevent them; it shortens the time between the failure and the correction.

There is a fourth failure mode the three above do not capture: taking work from friends without a commercial agreement. David Kravitz, Sliday’s co-founder, describes it as a choice he would want to reverse. Friendship can make it harder to settle scope, payment and each person’s contribution before work starts. Agree those terms before committing studio time. Without them, you risk giving away work without having chosen to make a gift.

Agile had its own failure modes, named and complained about from the first Snowbird retreat onwards. The common thread was that agile failed by frustrating the founder: wrapping her in rituals she had not chosen, pacing her in increments she did not need, billing her for the rituals every fortnight. This methodology will not fail in that direction, and founders who have lived through ten years of agile will be relieved by its absence.

It will fail in the other direction. It will fail because the founder is in the room, the founder has built something, the founder is emotionally invested and the studio’s instinct to be useful will tip, on a bad week, into the instinct to be agreeable. The editor will stay. The gate will be skipped. The scope document will reappear. The product will limp, and the engagement will end with a release that was shipped on time and never reached the metric anyone set at the start.

Every methodology has its preferred failure; this one fails by indulging the founder, where agile failed by frustrating them.