How To Scope An MVP That Ships In Six Weeks

Most first builds do not die because the team was slow. They die because nobody had the nerve to cut scope. A founder starts with a clear idea, then over six weeks of planning the idea grows a settings page, three user roles, a notifications system, an admin dashboard, and an integrations tab, and the eight-week build is now an eight-month build that has never met a real customer.

A six-week MVP is not a smaller version of the eventual product. It is a different thing with a different job. Its job is to answer the one question you are most afraid to ask out loud, using the smallest amount of software that can answer it honestly. Everything that does not serve that question is not "later," it is "not this build."

Name the riskiest assumption before you name a single feature

Before anyone writes code or even a feature list, write down the single assumption that, if it turns out to be wrong, kills the whole thing. For most products that assumption is demand: will the specific people you are targeting actually use this and pay for it. For some it is feasibility, for a few it is distribution or unit economics. But it is almost always one thing, and you usually know what it is even when you would rather not look at it directly.

This matters because it gives every later decision a single criterion. The MVP is the smallest piece of software that lets a real user act in a way that proves or disproves that assumption. Not the smallest version of your roadmap. The smallest test of your riskiest belief. That same discipline shapes the harder calls that come later too, like whether your first software hire should even be a developer and how to set a software budget that survives your runway.

If your assumption is "salespeople will log their calls if logging takes one tap instead of five," then the MVP is the one-tap logger and the proof that they keep doing it. It is not a CRM. The CRM is the thing you get to build after the assumption holds. The same one-question discipline is what separates a real validation build from the technical debt that quietly kills your roadmap when you skip it and just keep adding.

Pick one workflow, end to end, and make it complete

A modern MVP is one complete workflow that delivers a clear outcome to a specific user. Not five workflows. One. The sequence of steps a user takes to get the exact thing they came for, working all the way through, not a beautiful front half that dead-ends in a "coming soon."

The discipline here is in the word complete. Founders cut scope in the wrong dimension. They keep five half-built workflows because each one demos well, when they should keep one workflow that actually works from first click to finished result. A user cannot fall in love with a workflow that stops at step three. They can fall in love with one that gets them all the way to the outcome, even if it is the only thing the product does.

So write down the single workflow your product exists to solve. The one that, if it worked perfectly, would make your target user say "I need this." Then build that, fully, and nothing alongside it.

Sort everything else into "must prove," "must ship," and "defer"

Once the workflow is named, every proposed feature sorts cleanly into a short ladder:

• Must prove. The pieces that directly test the riskiest assumption. These are non-negotiable.
• Must ship. The pieces that make the one workflow function end to end. Auth if the user has to log in, a way to enter data, a visible result.
• Must support. The minimum that stops operational chaos, usually basic error handling and a way for you to see what users actually did.
• Defer. Everything else. Roles, dashboards, settings, integrations, the second workflow, the third.

The most important column is the one you defer. MoSCoW prioritisation calls it the "won't-have" column, and it is the part teams skip and then regret. Writing down explicitly what you are not building does two things. It stops scope creep, because there is now a documented decision to point at. And it reassures the stakeholder whose pet feature got cut that their idea was not forgotten, it was scheduled.

Keep that list visible. Scope creep almost never arrives as "let us add a huge feature." It arrives as a string of reasonable-sounding small additions, each one defensible on its own, that together push your launch out by months. The defence is a single question asked of every new idea: does this directly help us learn whether users will pay to solve this problem? If the honest answer is no, it goes in the deferred column, no matter how good the idea is.

Six weeks is a real timeline now, with a caveat

The timeline is achievable. A focused MVP with a handful of features lands in six to eight weeks once scope is locked, and AI-assisted development has compressed the build half of that further. Whether you reach for that speed in-house or through a partner is the other early call, and build vs buy and in-house vs outsourced velocity is worth settling before week one. The phrase to underline is "once scope is locked." The biggest variable in MVP timelines is not team size or tooling. It is how disciplined you were about cutting scope before the build started. A locked scope ships in six weeks. An open one ships never.

The caveat is that "build it fast" is not the same as "build it disposable." The parts a real customer touches still have to work. If your assumption is about payment, the payment path has to actually take money and the webhooks have to be verified before they move money, because a checkout that double-charges or silently fails teaches you nothing about demand and a lot about your support inbox. If your assumption depends on the app being up when someone tries it, it needs to actually be up, which is why what every hour of downtime actually costs is worth knowing even at MVP stage. The MVP is small in scope, not sloppy in the parts that exist. This is the line we hold when we build web apps for founders: ruthless about cutting features, uncompromising about the few that ship.

What to deliberately leave ugly

A six-week MVP earns its speed by being unapologetically incomplete in the right places. Some things you should leave deliberately unbuilt:

• Admin tooling. You can run the back office by hand or with a database client for the first hundred users. Do not build an admin panel to serve a customer base you do not yet have.
• Edge-case onboarding. Support the one path the workflow needs. The forgot-password-while-mid-checkout-on-a-flaky-network scenario can wait until you have users who hit it.
• Scale infrastructure. Build for the load you actually expect in the validation window, not the load you hope for in year two. Premature scaling is the most expensive way to feel productive, and most of the cloud bill you could cut in half comes from infrastructure provisioned for a future that has not arrived. The same logic governs self-hosting versus managed cloud and the true cost founders miss at this stage.
• The second persona. If you have two target users, pick the one whose behaviour best tests the assumption and build only for them.

None of this is permission to ship something broken. It is permission to ship something narrow. The user touching your one workflow should not be able to tell that the rest of the product does not exist yet, because from inside that workflow, the rest of the product is irrelevant to them.

The decision the build is waiting on

When the six weeks are up, the MVP has done its job whether the answer is yes or no. If users move through the workflow and come back and pay, your riskiest assumption held and you have earned the right to build the next layer. If they do not, you learned that in six weeks and a small budget instead of in eight months and a large one. Both outcomes are wins, because both are information you could not have gotten any cheaper.

The trap is treating the MVP as version one of the product you already designed in your head. It is not. It is a question, asked in code, of real people. Keep it that small, make the one workflow genuinely complete, and you will know more after six weeks than most teams know after a year of careful, uncut building. If you want a partner who will argue you out of the features you do not need yet, that is the conversation we like having.