MVP Development: What to Build in the First 6 Weeks (and What to Leave Out)

Six weeks is a deliberately short time to build a product. That is the point. Every team we work with starts with a feature list that would take six months, and the most useful thing we do in week one is not writing code; it is arguing the list down to the one flow that proves or disproves the idea. This guide is how we structure that argument and the five weeks that follow it. It is written for founders and product leads who have a build about to start, with us or with anyone else.

What an MVP is, and what it is not

The phrase has been diluted. In its original sense, from Eric Ries’s The Lean Startup, a minimum viable product is the smallest thing you can put in front of real users to learn whether the idea holds. “Minimum” is about scope; “viable” is about the user being able to get real value from it. Both words carry weight.

An MVP is not a prototype. A prototype is clickable and fake; it tests whether people understand the idea. An MVP is real: it stores data, charges money if money is part of the question, and keeps working after the demo ends.

An MVP is also not “version one of the full product, done quickly”. That framing is how six-week builds become sixteen-week builds. The first release is an experiment with a hypothesis, and features that do not serve the hypothesis are not cheap extras; they are noise that makes the result harder to read.

The one question to settle before week one

Write down the riskiest assumption in one sentence. Examples from projects we have scoped, generalised:

• “Clinic receptionists will accept bookings made online rather than by phone.”
• “Logistics managers will pay for live driver location instead of calling drivers.”
• “Small retailers will let a tool reorder stock for them automatically.”

The MVP exists to test that sentence. Each feature on the list then faces one filter: does the user need it to get through the flow that tests the assumption? If not, it waits. This is harder than it sounds, because the features that get cut are usually the ones the founder is most attached to, and because “while we’re at it” is the most expensive phrase in software.

The output of this exercise is a one-page scope: the core flow as a numbered list of steps, the user types involved (ideally one), and a short list of what is explicitly out. That page is signed off before any code is written. In our process it comes out of the week-one workshop and becomes the basis of the written quote.

What the first release must include

Beyond the core flow itself, a handful of things are not optional, because without them you cannot learn from the release or operate it safely.

Sign-in that works. Email magic links or a social login are enough. Do not build roles, teams and permissions unless the core flow needs two different kinds of user in the first week.

The core flow, end to end. Every step a user takes from arriving to getting the result, including the empty states, the error states and the confirmation. One flow, fully finished, beats three flows at 80%.

Payment, if payment is the test. If the assumption is “people will pay for this”, the MVP has to take money. A hosted checkout from Stripe or Razorpay is a day’s work; a custom billing system is not. If payment is not the test, leave it out entirely and collect intent another way.

Analytics on the flow. Instrument the steps of the core flow before launch: who started, who finished, where they dropped. The GA4 guidance on key events or any product-analytics tool will do. A release you cannot measure is a release you cannot learn from.

An admin view. Not a dashboard; a plain screen where you can see the users, the records they created and the state they are in, with the ability to fix a record by hand. In the first month, this screen is where operations happen.

Deployment, monitoring and backups. Production on your own cloud account, a pipeline that deploys on merge, error reporting, uptime alerting and an automated database backup. These are infrastructure, not features, and they are included in the six weeks because an MVP that falls over on launch day teaches you nothing about the idea.

The legal minimum. A privacy notice that is true, terms the business can stand behind, and consent where the law requires it. If you handle health, financial or children’s data, the compliance work moves into the core scope rather than after it.

What to leave out of the first release

These are the most common additions that add weeks and prove nothing:

• Native iOS and Android apps. A mobile-first web app that users can install to their home screen gets you on phones without store review. Build native when the test needs push notifications, camera or background location, or when store presence is the test. Google’s progressive web app documentation covers what the web can do today.
• Multiple user roles. Each role is a second product. Start with one.
• A reporting suite. Export to CSV is a feature; a dashboard builder is a quarter.
• Integrations with everything. One integration that the core flow requires, built properly. The others go on the list for later.
• Custom design systems and animation. A clean, consistent interface built from a proven component library is faster and, early on, more credible than a bespoke one. Brand polish belongs to the release after you know the flow is right.
• Internationalisation. One language, one currency, one timezone, unless the assumption is about a specific market.
• Scalability work. A well-built MVP on a managed database and a standard web framework will handle the first thousand users without heroics. Optimise once you can see the real load.
• AI features that are not the product. If the assumption is about an AI capability, it is the core flow. If it is a chatbot in the corner, it is a distraction.

A useful discipline: keep a visible “not now” list on the project board. Nothing is rejected; it is sequenced. Founders find it much easier to defer a feature than to delete it.

The six weeks, week by week

This is our standard shape. Teams working differently will recognise the stages even if the labels differ.

Week 1: scope, prototype, foundations

The workshop produces the one-page scope and the written quote. In parallel, the tech lead sets up what every later week depends on: the repository in your GitHub, the staging environment, the deployment pipeline, authentication and the data model for the core flow. By Friday there is a preview URL that updates on every push, and a clickable prototype of the core flow built from real components, which you can put in front of three or four target users over the weekend. Their reactions reshape week two more than any internal debate will.

Week 2: the core flow, ugly but real

The whole flow exists end to end on staging, with real data and a plain interface. Nothing is polished; everything works. This is the week to discover that step four of the flow needs information the user does not have yet, or that the “simple” calculation has six edge cases. Finding that now costs a day. Finding it in week five costs the launch.

Week 3: the edges

Empty states, validation, error handling, the confirmation email, the admin view, the analytics events. This is the unglamorous week that separates a demo from a product. It is also the week where the “not now” list grows fastest, because seeing the flow work makes everyone think of what it could also do.

Week 4: payment, notifications, the second pass on the interface

Whatever the test requires beyond the flow goes in now: the checkout, the reminder email, the one integration. The interface gets its second pass: consistent spacing, sensible copy, the states a real user will hit. Friday’s demo should be something you would show a customer.

Week 5: hardening

A test pass by someone who did not build it, on real phones and slow connections. Load the database with realistic data and see what slows down. Fix the security basics: rate limits, input validation, secure headers, secrets out of the code. Rehearse the launch: deploy to production, run through the flow, roll back, deploy again. Write the two-page operations note that tells you what to do when something breaks at midnight.

Week 6: launch and hand-off

Production deployment, the first real users through the door, and the team watching the analytics and error reports in real time. The hand-off is the documentation, the repositories transferred, the pipeline running in your account and a session with whoever will own the product next. In our engagements this week also includes the start of a thirty-day fix window, because the first real users will find things no test pass did.

How to run it so the six weeks hold

The plan above fails for predictable reasons. Three habits prevent most of them.

Decide within a day. The build has a named decision-maker on the client side who answers questions the same day. A six-week plan has no room for a question that waits a week. If the decision-maker is unavailable, the tech lead decides and writes the decision down.

Demo every Friday. Working software, on staging, walked through by the team, with the client clicking. Not slides, not a video. Weekly demos make scope creep visible early and make it obvious when the plan is slipping.

Change scope by trading, not adding. Anything added in weeks two to five is traded for something of equal size that moves to the “not now” list. The six weeks are a fixed container; the contents are negotiable, the container is not. This is the single rule that keeps fixed-price builds fixed.

After the launch

The MVP is finished when it is in front of real users and you can see what they do. That is the start of the useful part, not the end. Plan two to four weeks of measured use before committing to the next build phase, and go into that phase with the analytics open: which step do people abandon, do they come back, did anyone pay. The feature list for phase two is written from those numbers, and it is usually very different from the original list, which is exactly the outcome the six weeks were for.

If you are scoping a first release now, the project scoper will give you a team shape and timeline for the flow you have in mind, and our MVP package describes how the six weeks are run and what is included. If you would rather talk it through, a tech lead will tell you honestly whether the scope fits.