The practical answer
A clean MVP is usually measured in weeks, not months.
If your “MVP” estimate is drifting into multi-month territory, it’s often a scope problem, not a coding problem.
Rule of thumb
An MVP is the smallest version that can validate a core hypothesis. Not “v1 of the full product,” not “all features but fewer.”
Point-wise breakdown: what actually consumes time
- Scope definition: deciding what the MVP is (and isn’t), the user flow, the “one thing” it must prove.
- UI pages: each page isn’t just UI — it’s state, loading/error states, and edge cases.
- Integrations: auth, database, analytics, SEO, hosting/deploy pipelines.
- Data modeling: even simple apps need clean schema + constraints + indexes (or you’ll pay later).
- QA + polish: responsive issues, performance, and “death by a thousand papercuts.”
- Iteration: early user feedback almost always changes onboarding, pricing, or the core flow.
A simple “MVP timeline map”
1) Clarify the problem
Write the user story + success metric. If you can’t explain it in 2–3 lines, it’s too big.
2) Pick the minimum flow
Sketch 3–6 screens. Cut anything that doesn’t serve the core loop.
3) Build the backbone
Auth + DB + API routes + core data model. Keep it boring and reliable.
4) Ship & measure
Deploy, add analytics, do basic SEO, and get 5–10 humans using it.
Common timeline traps
- “Just one more feature” (usually roles + permissions + dashboards).
- Unclear acceptance criteria (“I’ll know it when I see it”).
- Underestimating integrations and QA on real devices/browsers.