The 4–8 week MVP: what fits, and what quietly blows your timeline

Most “MVPs” fail the M. They’re neither minimal nor viable — they’re a six-month build wearing a startup costume. A real MVP answers one question: will people use this enough to justify building more?

What fits in 4–8 weeks

• One core workflow, done well, end to end.
• A single primary user role.
• The happy path plus the two most likely error states.
• Auth, but the boring kind — email and a password, or a single SSO provider.

That’s it. Everything you ship should serve the one question above.

What quietly blows the timeline

Some features look small on a roadmap and detonate in the build:

• Real-time anything. Websockets, presence, live collaboration — each doubles your testing surface.
• Granular permissions. “Just add roles” becomes a permissions matrix nobody scoped.
• Multi-tenancy retrofitted late instead of decided on day one.
• Native mobile alongside web, when a responsive PWA would have proven the point.

If a feature doesn’t change the answer to “will people use this?”, it isn’t MVP scope.

Lock scope, then protect it

We start every engagement with a one-week discovery that ends in a written, fixed scope. The discipline isn’t in writing it — it’s in defending it when the inevitable “while we’re at it…” arrives. Park those ideas in a v2 list. Ship the MVP. Let real usage tell you which of them were ever worth building.