The MVP Mirage

Field Notes on Building, Budgeting, and Bullshit Deadlines

In consulting, we love the myth of “getting shit done.”
MVPs. Agile sprints. Two-pizza teams. The whole story we tell about how we move fast and break things — with just enough scope to ship something real.

But here’s the thing: scope is never fixed.
Not really.

You walk into a project with a defined MVP. But the moment the client sees what they aren’t getting, the shape starts to shift. That scope you spent two weeks aligning on? It evaporates the second a stakeholder asks, “But can it also…?”

And now you’re no longer delivering an MVP — you’re delivering a moving target under fixed time and budget constraints.

The classic triangle: time, budget, scope.
Everyone claims to understand it.
But in practice?

• Time gets compressed.
• Budget gets locked.
• Scope gets quietly inflated — not by bad actors, but by good intentions and evolving insight.

And scope isn’t just “features.”
It’s complexity. It determines the effort across both time and space. It tells you how much thinking you need to do up front — and what kind of people you need to do it.

More scope = more expertise.
More expertise = higher cost.
Cutting that cost? That’s how you end up with the wrong people solving the wrong problems with the wrong tools.

What’s worse is that clients don’t want to cut scope.
So they cut time. Or they cut team size.
Or they bring in tools to "go faster" — AI, low-code, prefab templates — without the surrounding clarity to know when they’re helping and when they’re just speeding up the drift.

And that’s how you burn weeks building to spec…
Only to find you nailed the wrong problem.

None of this is new.
We’ve been here before.

People have been calling this out for years — quietly in retros, sometimes loudly in articles and case studies. There are entire postmortems that show how projects could’ve succeeded if the org had just invested early in the right people, the right framing, and the time to think. Not more money, better-spent money.

Instead, the same cycle: underfund discovery, under-staff architecture, then wonder why delivery is chaotic.

I felt this again recently while building two sites — nino.photos and letspepper.com. On the surface, both were clean builds. MVPs, even. But they only look fast and light because I knew exactly where to spend time, what to defer, and where AI could support instead of mislead.

AI was an accelerator, not a replacement.
But that only worked because I already had the experience to ride the bike.

So here’s the hard truth:
If you want to move fast, you need the right scaffolding — clear problem framing, smart resourcing, and the discipline to say no to scope until you’re ready.

Otherwise, “just ship it” becomes “just rebuild it later.”