MVP scope & timeline estimator

How long it really takes to build an MVP

An MVP is the smallest product that lets real users get the core value and lets you learn whether they will pay for it. Most MVPs that take six months are not slow because the team is slow. They are slow because the scope quietly grew into version two before version one shipped.

With the defaults (a lean web app, one senior, sign-up, profiles, payments, notifications, an admin dashboard and onboarding around one core workflow) the estimate comes out at about seven weeks, with a range of six to nine. Switch to polished and it is about eight and a half; add cross-platform mobile on top of web and it is closer to eleven and a half.

How the estimate works

• Features carry design, build and QA estimates in person-days for one senior using managed services: a hosted auth provider, Stripe, a hosted database. Your core workflow adds a fixed 10.5 days on top.
• Platforms scale the work. Back end and logic are shared, so a second platform adds about 60% more build, 30% more design and 50% more QA, not double.
• Polish multiplies design hardest (up to 1.9× for premium), build and QA less.
• Team sets how many people work in parallel and how much coordination overhead that adds. Phases overlap more with a team, but discovery, design sign-off and launch do not split well.

The range runs from 15% under to 30% over the most likely figure, because software estimates miss late far more often than early. Plan on the upper number.

Reference effort for common features

What to cut from an MVP

Turn on Hit a deadline and the estimator defers features in a deliberate order, starting with the ones that almost never decide whether an early product succeeds: multi-language support, in-app reporting, a custom admin panel, integrations, maps, and roles and permissions. Sign-up, payments and AI features are cut last, because they are usually the point. It then puts back anything that still fits, so you keep as much as the date allows.

Every cut comes with what to ship instead. That is the real skill of scoping: not saying no, but finding the version of a feature that costs a day instead of a week. An admin dashboard can be your database's own table editor for the first hundred users. Chat can be email. Payments can be a link.

Rules that keep an MVP on schedule

• Fix the date, flex the scope. Decide the launch week first and let features compete for the time.
• One workflow, done properly. The thing people pay for should feel finished; everything around it can be plain.
• Write down what is out. A list of deferred features stops them creeping back in week three.
• Buy, don't build, the commodity parts. Auth, payments, email and file storage are solved problems.

This is the logic behind my fixed-scope Ship It Live sprints: the SaaS MVP in 30 days, AI app in 30 days, iOS and Android in 30 days and web app in 21 days. They are fast because the scope is agreed first and held. If you are not yet sure what v1 should be, product discovery in 5 days turns the idea into a written scope. For larger builds, see AI app development and web app design.