How to Scope an MVP So It Ships in Weeks, Not Quarters

Most MVPs are late for the same reason: nobody wrote down what was out. The feature list grew one reasonable line at a time, and the "minimum" product now has user roles, a settings area, a mobile app and an admin dashboard. Getting the MVP scope right is less about choosing features than about choosing one user, one job and one result, then defending that choice in writing.

This is the sequence we take founders through before anyone estimates anything, and it produces a single page. To keep it concrete, one made-up product runs through every step: a web tool that lets small physiotherapy clinics send patients their home exercise plans.

Pick one user and one job

"Clinics" is a market, not a user. A user is a person you could phone: the physiotherapist in a practice of one to five people who prints exercise sheets and hands them over at the end of a session. The job is the one thing that person will use the product to get done: send a patient a plan they can follow at home.

Write it as a single sentence in this shape: [this person] can [do this job] without [the workaround they use today]. For the example: a physiotherapist can send a patient a clear exercise plan in two minutes without printing anything.

Other people will touch the product, and each gets the thinnest version that lets the main job happen. The patient receives a link and never creates an account. Any feature that does not serve the sentence has to argue its way in.

Set a measurable goal before you list features

An MVP exists to answer a question, usually "will the people we built this for keep using it?" Write the answer you hope for as a number attached to a behavior, such as: ten clinics send plans in three consecutive weeks without being reminded by us.

"Launch" is not a goal, and neither is "get feedback". A proper goal does two things for the scope. It tells you what must be measured from the first day, which here means recording each plan sent, per clinic, per week. And it gives you a test for every proposed feature: could this plausibly move that number in the first release?

Walk the job end to end, then sort must, should and could

List the five or six steps the user goes through from arriving to getting the result. Under each, write every way you have imagined doing it, then sort those ideas into three columns with one question: if this is missing, can the one user still complete the one job?

Part of the job	Must	Should	Could
Getting in	Sign up with email, reset a password	Invite a second practitioner	Single sign-on
Building a plan	Pick exercises from a fixed library, set repetitions	Save a plan as a template	Upload your own exercise videos
Sending it	A private link by email	A text message as well	A branded patient app
Knowing it worked	See whether the patient opened the plan	Patient ticks off exercises	Progress charts
Paying	One plan, one price, by card	Annual billing	Per-seat pricing, coupons

The first release is the Must column and nothing else. "Should" means the user will feel the gap but has a workaround, which is what makes it safe to postpone. If nearly everything landed in the first column, go through it again with someone who is not attached to the ideas.

Protect the MVP scope with a written cut list

The Should and Could columns are the start of a cut list. Add everything else that came up in conversation, and for each item write the reason it is out and the event that would bring it back. For the example:

• Native mobile apps. Out because the patient only needs a link and the clinician works at a desk. Back when clinics ask to build plans on a tablet during sessions.
• Roles and permissions. Out because everyone in a five-person clinic can see everything. Back when the first multi-site customer signs.
• Reporting. Out because we can answer any question with a database query. Back when customers ask for figures we are producing by hand each week.

This list is the most useful document in the project. When an investor, an early customer or a co-founder asks for something halfway through the build, the answer is already written, with its reason. The rule for changing it is simple: something comes into scope only if something of similar size goes out, or the date moves and everyone says so aloud.

Do the unglamorous parts by hand

A first release does not need software for work a person can do a few times a week. The user experiences a complete product, and behind it sits a founder with a spreadsheet. In the example:

• Onboarding is a video call, and you create the clinic's account yourself.
• The exercise library is loaded into the database by a developer, with no editing screen.
• The weekly usage figures for your goal come from one saved query.

Each of these replaces a feature you would probably build wrong, because you have not yet seen how customers use it. Doing the task manually a dozen times teaches you what the feature should be. Automate it when the manual version costs more time each month than the feature would take to write.

There are limits. Do not hand-edit payment records, do not handle card details yourself, and do not tell customers something is automated when a person is doing it.

Keep the things you cannot bolt on later

Cutting scope is about features, not foundations, where shortcuts become expensive or dangerous within months:

• Authentication. Use what your framework provides. Laravel's starter kits, for instance, include registration, login, password reset and email verification. The OWASP Authentication Cheat Sheet lists what a login has to get right.
• Separation between customers. One clinic must never see another's patients. Decide on day one how tenant data is kept apart, and test it.
• The core data model. Screens are cheap to rewrite. Moving live customer data into a different structure is not.
• Payments through a provider. Use the provider's hosted checkout so card numbers never reach your server.
• Backups, error logging and uptime alerts. A restore you have tested, a log you read and a message when the site is down.
• Privacy basics. A privacy policy that matches what the product does, and a way to delete a customer's data on request. A product that holds health information, like our example, carries extra legal duties in many countries, so get advice before launch.

Buy before you build: authentication, billing, email delivery and file storage are solved problems. Our guide to choosing a tech stack for a SaaS MVP covers those choices.

Fix the date and let the scope give way

With the page written, choose a release date and treat it as the fixed point. When a must-have turns out harder than expected, simplify it or drop something beside it. A date that moves once will move again.

Three habits make this workable. Show working software to a real user every week. Build the whole path thinly first (sign up, make a plan, send it, see it opened) before making any step good. And keep to one platform: a responsive web application reaches clinicians at a desk and patients on a phone without a second codebase.

How many weeks that takes depends on the team and on details only an estimate can show, but a scope with one user role, one main path and a handful of screens is the kind that fits in weeks. We explain why the figure is a range in how software estimates work and why they change.

Who should do the scoping

A founder can do the first four steps alone, and should, because they are business decisions. The last three benefit from a developer in the room. What is cheap and what is expensive is not obvious from outside: sending a text message is a small job with the right provider, while "just a simple permissions system" can take longer than the rest of the product.

If you have no technical co-founder, ask for a short scoping phase before a full quote, and bring the one-page scope and the cut list to it. That is how we start projects with startups and SaaS companies. The consultation and the quote are free, and you own the source code of what we build. For products headed toward subscriptions, our SaaS product development page describes the architecture decisions that follow.

Frequently asked questions

What is the difference between an MVP and a prototype?

A prototype tests whether people understand and want the idea. It can be a clickable design with no real data behind it. An MVP is working software that real users rely on to do the real job, with their own data and usually their own money.

Should the MVP be a mobile app or a web app?

Usually a responsive web application, because it reaches every device with one codebase and can be updated without an app store review. Start with a native or cross-platform app only when the core job depends on something the phone provides, such as the camera, offline use or push notifications.

Will the MVP code have to be thrown away later?

Not if the foundations were done properly. Screens and flows will be rewritten as you learn, which is normal. What should survive is the data model, authentication, the separation between customers and the payment integration.