The honest answer
A focused MVP can usually ship in a few weeks rather than months — if the scope is narrowed to the single thing that proves the idea is worth pursuing.
The slowest MVPs aren't slow because of code. They're slow because of indecision, scope creep, and premature scaling. Fix those three and the engineering tends to take care of itself.
What actually sets the timeline
It helps to separate the work into what is genuinely fixed and what is a choice.
| Usually fixed | Usually a choice |
|---|---|
| Core flow that proves the idea | Second and third user types |
| Sign-in and basic account handling | Settings, preferences, profile pages |
| App store review (for mobile) | Admin dashboards |
| Payment integration, if you charge on day one | Custom infrastructure and "future-proof" architecture |
The left column is small. Nearly everything that turns a six-week project into a six-month one lives on the right.
What makes an MVP fast
Pick one job and do it well. An MVP that does one thing convincingly beats one that does five things poorly. Write down the single sentence a first user would say about it — "it does my bookkeeping from a photo of a receipt" — and cut whatever doesn't serve that sentence.
Decide quickly and reversibly. Most early decisions are cheap to change later; treating them as permanent is what creates delay. Reserve careful deliberation for the few choices that are genuinely hard to undo, such as your data model and anything users will pay for.
Build for today's scale. You can re-architect once you have traction — and you'll do it better with real usage data. As Paul Graham puts it in Do Things That Don't Scale, the early stage is exactly when doing things manually is the right call.
Buy the boring parts. Authentication, payments, email, file storage, and analytics are solved problems. Renting them costs a little money and saves weeks.
What makes an MVP slow
- A committee of deciders. Every extra person who must approve a screen adds days. Give one person the final say.
- Designing every state up front. Design the main flow properly and let the edges be plain until users show you which edges matter.
- "While we're at it." Each small addition seems free. Together they're the difference between weeks and months.
- Building the platform before the product. Plug-in systems, multi-tenancy, and elaborate permission models are answers to problems you don't have yet.
Fast doesn't mean throwaway
There's a difference between cutting scope and cutting quality. Cutting scope makes you faster now and later. Cutting quality — no tests around the core flow, no structure, secrets pasted into the code — makes you faster for about three weeks and then slower for as long as the product lives.
The goal is a small product built properly, not a large product built badly. A small, clean codebase is also the cheapest thing to change when users tell you what they actually want.
Where AI changes the picture
AI features compress some timelines and stretch others. A capable model can replace months of rules-based logic with a well-written prompt and a few tools. But AI features also need something conventional features don't: a way to check the output is good enough, repeatedly, as you change things. Budget time for that from the start, or the demo will work and the product won't.
More on scoping and sequencing in the Shipping AI products fast series.