Why we ship an MVP in 72 hours, not 72 days

72 hours isn't a stunt. It's what's left once you remove everything from a build that doesn't change whether the underlying idea actually works — the parts teams spend the first month on because they feel like progress, not because a user needs them yet.
That usually means: one core flow, not five. Auth that works, not auth that scales to a million users you don't have yet. A database schema you're willing to migrate later, because you will, once real usage tells you what "later" needs to look like.
The scope call happens in hour zero, on a call, not in a written proposal that takes a week to turn around. You leave that call with a fixed price and a list of what's explicitly out — which matters more than the list of what's in, because that's the list that keeps the sprint from quietly becoming six weeks.
What ships at hour 72 is real: a live URL, a real deploy pipeline, real (if minimal) monitoring. Not a prototype you'd need to rebuild before a second user could touch it. The hardening — load testing, error budgets, the boring week-two work — comes after, once you know the idea is worth hardening.
The bet this makes: a founder learns more from a rough thing 12 real users touched this week than from a polished thing that ships in six weeks to nobody. Most of the time, that bet is right.
Have a question about this article — or your own project?
Ask us anything about the approach above, or tell us what you're building. You'll hear back from an engineer, not a sales script.