This is a postmortem for an MVP that shipped sixteen weeks late. No single decision caused it. That is the finding. The project died the way most MVPs die — not from a bad rewrite or a vendor collapse, but from scope absorbed silently, four days at a time, by people acting reasonably. The case below is a composite of a pattern the lab has seen enough times to name; details are merged from several real projects, numbers representative.
The system
A B2B field-services company. The MVP: quoting and job tracking — replace a spreadsheet-and-email pipeline with one system where a quote becomes a job becomes an invoice. Scoped at six weeks, roughly $28k. One workflow, three roles, one integration (accounting export). A written scope existed. It was two pages. It listed what the system did. It did not list what the system did not do. Remember that.
Timeline
- Weeks 1–2. On plan. Data model, auth, quote builder.
- Week 3. First demo. It goes well — too well. "Can it text the customer when the quote goes out?" SMS was not in scope. It is small: one provider, one template. Absorbed. Days added: 4.
- Week 4. SMS needs delivery-failure handling and opt-out, because carriers require both. Nobody reopens the scope document; this is "part of the SMS thing". Days added: 3.
- Week 5. Second demo. The ops manager asks for a fourth role: subcontractors who see jobs but not prices. Per-object permissions were explicitly not in the data model. The request is agreed to verbally, in the meeting, in under a minute. Days added: 8.
- Week 7. The permissions change ripples: every list view, every export, the notification templates. The demo audience calls the product's new "small CRM feeling" a win. Days added: 6.
- Week 9. Reporting. "Just a dashboard — job counts and revenue by month." The first chart library enters the build. Days added: 7.
- Week 12. The accounting export — the one scoped integration — has not started.
- Week 14. A "quick wins" list circulates with eleven items. Nobody can say which are in scope, because the scope document no longer describes the system.
- Week 16. The budget conversation. Genuine surprise on both sides — which is the tell. Neither side had been keeping score, because no mechanism existed for keeping score.
- Week 22. Ship. 3.5x the timeline, 2.3x the cost. Both parties relieved rather than proud. The system works. The trust is spent.
The mechanism: absorption
Each addition was individually rational. SMS: genuinely small. The subcontractor role: a real business need. The dashboard: reasonable to want. Nothing on the list was a bad idea — and that is exactly why the process failed. Every safeguard people imagine ("we push back on bad ideas") was aimed at a threat that never showed up. The threat was good ideas, arriving one at a time, each small enough to absorb.
SILENT_SCOPE_ABSORPTION
A change enters the build through conversation — a demo comment, a Slack message, a "while you're in there" — without being priced, scheduled, or traded against anything. The cost is real but recorded nowhere, so the project's stated plan and its actual contents diverge a little more each week. The gap stays invisible until the calendar announces it, and it is announced as a betrayal: each side genuinely believes the other one moved the line, because the line was never written down as it moved.
Absorption is not an estimation failure. The original six-week estimate was accurate — for the original scope. The estimate was never wrong. The thing being estimated was quietly replaced.
The ratchet: demo-driven development
Weekly demos were supposed to be the safety mechanism. In this project they were the ratchet. A demo rewards what a demo can show: new screens, visible features, things that click. It cannot show idempotent webhook handling, permission tests, or migration scripts — so under demo pressure, invisible work loses to visible work every single week. Two consequences compound:
- Every demo generates requests, because engaged stakeholders looking at real screens is precisely the machine that produces ideas. That is the point of demos. Without a pricing mechanism attached to it, it is also the leak.
- Hardening slides. The failure-handling and integration work — scoped, budgeted, essential — kept losing the weekly argument to features that could be seen. The accounting export sat untouched for nine weeks, not because anyone decided to deprioritize it, but because no demo ever asked to see it.
The ratchet turns one way. No demo in history has concluded with "this should do less."
The fix
Three artifacts. None of them clever. All of them boring on purpose.
A scope with failure boundaries. Not just what the system does — what it explicitly does not do, and what it does when things fail. "No per-object permissions; roles are admin, office, tech" is one sentence, and it would have converted the week-5 verbal yes into a visible scope change. The boundary sentence is the tripwire. Without it, there is nothing to trip.
Change requests as artifacts. One page or less: what, why, cost in days, what it displaces. Fifteen minutes to write. The subcontractor role as a change request reads "8 days, delays accounting export by the same" — and at that visible price, the client rationally defers it to phase two. Writing it down is not bureaucracy; it is the only way the cost of a yes becomes visible before it is paid. The politics improve too: "yes, via change request" is a warmer answer than "no", and nobody ever has to argue against a good idea in a meeting.
Phase gates. The build does not roll forward continuously; it passes named gates — scope frozen, build complete, hardening complete, launch. New ideas land in the next phase's backlog by default, not in the current phase's week. The gate converts "while you're in there" into "in phase two", which is where most of it belonged all along.
Constraint
The process is not "no changes". Change is expected — discovery during a build is normal and often valuable. The constraint is narrower: no silent changes. Anything that moves cost or time exists on paper before it enters the build. A project can absorb almost any change. What it cannot absorb is not knowing that it did.
What the line means
Norseson's process carries one sentence that this postmortem is the argument for: "Scope is defined before we build. Changes are explicit, not absorbed silently."
In practice: the scope document lists non-goals and failure boundaries, not just features. Every mid-build request gets a written cost before it gets a yes. Demo feedback routes into change requests or the phase-two backlog — never directly into the sprint. And the awkward budget conversation happens continuously, in one-page increments, instead of once, in week sixteen, as a surprise.
Run under those rules, the composite project above ships in eight or nine weeks — with SMS, without the mid-build permissions rework, and with both sides still pointing at the same piece of paper. That is the entire trick. There is no other trick.