Why most MVPs fail before code starts

Most failed MVPs do not fail because the engineering was sloppy. They fail because the team agreed to a shape that was wrong before anyone wrote a line of code. By the time the bug reports start, it is too late — the wrong thing has been built well.

This is the part of the work we now refuse to skip. Three weeks of decoding before we open an editor. If that is not the deal, we are not the team.

Marty Cagan calls this the discovery phase in Inspired. Teresa Torres calls it continuous discovery. Eric Ries called it build-measure-learn. The names rotate; the work is the same.

The shape problem

When operators talk about an MVP they almost always describe an artifact. A page, an app, a flow. A picture in their head of the product on day one. The engineer hears the artifact and starts breaking it into tickets.

That is the trap. The artifact is the output, not the problem. Two artifacts that look identical can solve completely different problems, and the one that ships is the one whose author misunderstood it least.

What we want before any commit is the shape of the problem:

• Who specifically loses sleep over this today?
• What does their current Tuesday afternoon look like?
• What is the next step they would take if this MVP did not exist?
• Where does money or trust currently leak?

If we cannot answer those four cold, we are not ready to write the spec. We are ready to spend another week interviewing — and the interviewing rules in The Mom Test apply harder than most teams admit.

Constraints are not negotiable

Every project comes with constraints the operator has already accepted without realising. Compliance, contractual obligations, an existing customer who must not be disrupted, a hardware target, a payment processor that will not budge.

We extract those before kickoff and write them at the top of the spec under a heading called Non-negotiable. Then we treat them like physics. They are not edge cases. They are the geometry of the room.

The bug we never had to fix is the one we wrote down at the start as: "this cannot ever happen."

When a constraint changes mid-build, that is a re-spec, not a tweak. The operator gets a one-pager describing what shifted and what it costs. They sign it or it does not happen. Basecamp's Shape Up calls this an appetite; we use the same word.

The thinnest valuable shape

Once we know the problem and the constraints, the next question is the thinnest version that is valuable. Not the thinnest version that demos. Valuable means: a real user runs it on real data and is glad they did.

A landing page with a Calendly link is a thin valuable shape. A signup flow with no product behind it is a thin valuable fraud. The distinction is whether the next person who clicks is better off. Paul Graham's "Do things that don't scale" is the polite version of this argument; we are the impolite version.

Three rules we use to test thinness:

1. If we remove this screen, does the user still get the value? If yes, remove it.
2. If we add a manual step (a human in the loop, a Postgres query), does the value still land? If yes, skip the code for it.
3. If we run this in production for two weeks, will the operator still want to scale it? If unclear, do not scale yet.

Why this maps to shipping faster

It looks slow on paper. Three weeks of decoding feels like three weeks of nothing. The first time a team works with us they usually push back on it.

But every project we have shipped where we cut decoding short has needed a partial rewrite within six months. Every one. The cost of a rewrite — operationally, politically, financially — is far higher than the cost of an extra week of clarity at the start. The DORA research has been saying this for a decade in the State of DevOps Report: the high-performing teams are not the ones cutting corners; they are the ones with the strongest engineering discipline upstream.

Move at the speed of clarity. Then move fast.

That is the order. Clarity first, code second. When we get that right, the MVP ships in less calendar time and survives contact with users.

What this looks like in practice

When we onboard a project, week one is dedicated to decoding — interviews, constraint mapping, drawing the system on a whiteboard until everyone in the room sees the same picture.

Week two is shaping — picking the thinnest valuable shape, writing it down, defining acceptance criteria and what we will not do. The non-goals section is non-negotiable; we treat the absence of a non-goals section as evidence that the spec is not done.

Week three is the plan — the actual implementation broken down into tasks under five minutes each, in order, with verification steps. By the time we open an editor, there is nothing left to decide. We just build.

Spec-driven development — the practice GitHub recently formalised under that name, but that we and many others have run informally for years — is the discipline that makes this repeatable. The artifact is a written spec; the engine is the discipline of not coding around it.

The MVPs that fail before code starts are the ones where any of these three weeks were skipped. The MVPs that ship are the ones where the operator was willing to spend them.

Further reading

• Inspired — Marty Cagan. The product-discovery canon.
• Shape Up — Ryan Singer / Basecamp. The 6-week cycle that influences how we scope.
• Continuous Discovery Habits — Teresa Torres. On the interview cadence behind shape.
• Do Things That Don't Scale — Paul Graham. The thinness argument, pre-2026.
• The Mom Test — Rob Fitzpatrick. On asking customers questions whose answers are actually useful.
• State of DevOps 2023 — DORA / Google Cloud. On why discipline beats speed in the medium term.

>  end of article · v0.1 · 2026