The Stages of an MVP Build: A Founder's Mental Model

What you actually need to know

• An MVP build has five stages. Each one has a primary risk and a correct founder behavior.
• The founder's role changes at every stage. Being in the right mode at the right time matters as much as the decisions made.
• The most expensive mistake on an MVP is applying week eight behavior in week three.
• The stage you are in determines which information is useful and which is noise.
• Knowing the stages does not make the build faster. It makes the decisions in each stage less expensive.

The core argument

The mental model I return to on every project is a simple one. An MVP build is not a creative process. It is an assembly process that happens to require creativity. The stages are defined by the work that can and cannot be done in each one, not by calendar dates. You cannot harden a feature that does not exist. You cannot add a feature mid-foundations without paying a real cost. The sequence matters because the dependencies are real.

Founders who have not shipped software before often treat the build as a flat timeline. They imagine that every week is the same kind of week, and that their input is equally useful at all points. It is not. In the scoping stage, the founder's input is critical. In the foundations stage, it is mostly a source of delay. In the soft launch stage, real user feedback is worth more than any founder intuition.

The result of not having this model is a founder who is maximally active at exactly the wrong times. Adding features during foundations. Hardening code that is about to change. Treating the soft launch as a moment for polish rather than for observation. Every one of those misapplications costs time and money that a correct staging would have preserved.

I am not saying founders should go silent. I am saying founders should know which stage they are in, understand what that stage needs from them, and calibrate their involvement accordingly. The build will be faster. The product will be better. The developer will stay engaged rather than drifting.

The five stages in detail

Stage one: scoping

This is the stage most teams rush. It is also the stage that determines whether the rest of the build is recoverable. The output of scoping is a written brief that names the problem, the user, the smallest useful feature set, the technical constraints, and the explicit out-of-scope list.

The founder's job is to cut the feature list down to the core. The developer's job is to validate technical feasibility and flag anything that is more complex than it appears. The brief that comes out of this stage is the reference document for the entire build. Every disagreement that arises later gets resolved by looking at the brief.

Stage two: foundations

Foundations is the stage where the scaffolding goes up. Authentication, database schema, deployment pipeline, third party service integrations, basic navigation structure. None of this is visible to the user yet. It is the infrastructure that every feature will be built on.

The founder's job in this stage is to be available for fast decisions. The developer will hit forks in the road where they need to choose between two approaches. The choice is usually about tradeoffs the founder is better positioned to make. Slow responses here add days to the timeline. New requirements here add weeks.

Stage three: feature build

This is the longest stage and the one with the most visible progress. Features are built, tested, and integrated week by week. The Friday demo cadence is the tool that keeps this stage on track. Each demo shows what was built that week. The founder gives feedback. The next week's list is set.

The primary risk here is scope creep. Every week, there will be a moment where a new feature seems necessary. The rule is that any addition made after the brief is signed goes through a deliberate cost conversation before entering the build. It does not get squeezed into an existing sprint. It waits for the next sprint or gets deferred to version two.

Stage four: production hardening

This stage is one week of work that most teams try to compress into two days. Error handling, loading states, transactional email, monitoring, real user testing. The details are covered in depth in the production MVP post, but the summary is this: a product that passes the demo test is not a product that passes the real user test. This stage closes that gap.

Stage five: soft launch

Soft launch is not a moment. It is a mode. You are shipping to real users, watching them, and fixing what they hit before you expand the user count. The ten user soft launch is worth more to the product than a hundred user public launch, because the ten user data is close enough to observe and the corrections are cheap enough to make quickly.

What it costs

What to look for in each stage

• Scoping: a written brief that includes an explicit out-of-scope list. No brief, no basis for decisions.
• Foundations: a working deployment to a real URL by the end of the stage. Something to click.
• Feature build: a demo every Friday. Not a slide deck. Working software.
• Production hardening: testing by people who were not involved in the build.
• Soft launch: session recordings or direct observation of the first ten users.

Expert opinion

The founders who stay out of the way at the right times and push back at the right times ship better products than the ones who are uniformly involved or uniformly hands off. The stages are the map for that calibration. They tell you when your job is to cut and when your job is to watch.

>

Yashveer Singh, founder of Yashveer Labs

How this played out on a real project

I ran this five stage model on a marketplace MVP build last year. Scoping took four days and produced a brief that cut the original feature list from twenty two items to nine. Foundations took ten days. Feature build ran six weeks with a Friday demo every week. Production hardening took six days, slightly over the estimate because the email configuration required an extra round of DNS troubleshooting. Soft launch started with eight users recruited personally by the founder.

By soft launch week three, the founder had identified two friction points that would never have appeared in a demo: the onboarding flow had an optional step that sixty percent of users were skipping, which made a required step later in the flow fail silently. Both were fixed inside a week. Neither would have been visible without real users in the product.

For the detailed cost structure underlying the stages, why cost always doubles covers the budget behavior that happens when stage discipline breaks down. For the scoping stage specifically, the three document pack every founder owes their developer covers the exact documents that come out of a well run scoping session.

Common mistakes

1. Skipping the written brief and calling the verbal discussion sufficient. Verbal briefs do not survive disagreements.
2. Adding requirements during foundations. Every addition here costs three times more than the same addition in scoping.
3. Missing a Friday demo and letting two weeks pass without seeing the integrated product.
4. Treating production hardening as optional. It is not. It is the stage that makes the product usable by people other than the team.
5. Launching to the public before doing a soft launch with ten known users. The public launch is harder to learn from.
6. Applying scoping-stage behavior during feature build. Week six is not the time to renegotiate the brief.
7. Conflating stage completion with feature completion. Moving to hardening when the core flow works, not when the full feature list is done.

A 10 week plan

1. Week one, days one to four. Scoping. Write the brief. Cut the list. Agree on the architecture. Get the brief signed by both sides.
2. Week one to two. Foundations. Authentication, database, deployment, third party integrations. Founder available for fast decisions only.
3. Weeks three to eight. Feature build. One demo every Friday. Founder attends every demo. Any scope additions go through a cost conversation before entering the next sprint.
4. Week nine. Production hardening. Error states, loading states, email, monitoring, outside user testing.
5. Week ten. Soft launch to ten users. Observe. Fix. Hold the roadmap.

For the founder's role at the soft launch stage, founder led sales during the MVP phase covers how the founder's attention shifts when real users enter the product. For scoping discipline, 7 MVP mistakes that destroy startups before they launch covers the brief and what happens without one.