All posts
Engineering

Why a good MVP still takes 10 weeks, not 10 days

AI tools compressed the wrong part of the timeline. Here's what actually determines how fast you can responsibly ship a first version.

Why a good MVP still takes 10 weeks, not 10 days

Every founder conversation starts the same way now: "With AI, can't this take a week?" Parts of it, yes. The part that used to be the bottleneck (writing boilerplate CRUD, scaffolding auth, wiring a basic UI) genuinely has compressed. But that was never the part that made MVPs slow.

The bottleneck moved, it didn't disappear

What actually eats weeks is deciding what NOT to build, reconciling conflicting stakeholder assumptions, and getting the data model right before hundreds of records depend on it. None of that is a typing-speed problem, so faster code generation doesn't touch it.

Faster code generation didn't remove the thinking. It just made the thinking more visible as the bottleneck.

Whiteboard planning session
Week one of most of our MVP engagements looks like this, not a code editor.

Where we actually spend the 10 weeks

Roughly: two weeks on scope and data modeling, four on the core build, two on integration and edge cases nobody mentioned in the kickoff call, and two on the unglamorous stuff: real error states, loading states, empty states, and the first round of actual user feedback.

0
Weeks, average MVP timeline

The teams that ship in 10 days either had 90% of that thinking already done, or they're going to redo the last 6 weeks later, just after it's live and expensive to fix.

Enjoyed this? Get more like it.

Get in touch