How to Scope an MVP You Can Ship in a Weekend

A first version should do one job, for one type of customer, in one situation. Everything else is deferred, and most of what remains can be done by hand rather than built. The test is not whether the product is finished. It is whether one person can get the outcome they wanted, even if you are personally involved in delivering it.

Building is no longer the bottleneck

For most of the last two decades, the honest reason first versions took months was that building took months. That excuse has expired. A working prototype of most software ideas is now a weekend of focused effort, and a service can be scoped and sold in an afternoon.

What has not changed is the tendency to build too much. If anything it has got worse, because when building is cheap it is tempting to add things instead of deciding.

So the discipline moves. The hard part is no longer construction, it is deciding what the product does not do, and being willing to ship something visibly incomplete to a real person.

Cut to one of everything

One customer type. Not small businesses. Independent physiotherapists with one location. The narrower the customer, the fewer decisions you face, because most product complexity comes from serving people who want different things.

One job. Not managing a practice. Getting patients to rebook. A product that does one job well is easier to explain, which matters more at this stage than being complete.

One situation. Not everywhere and always. On a phone, at the end of an appointment. Situations carry constraints, and constraints make design decisions for you.

If you cannot fill those three in one sentence each, the scope is still too wide, and no amount of building will fix that.

	Too wide	Scoped
Customer	Small businesses	Independent physiotherapists with one location
Job	Managing a practice	Getting patients to rebook
Situation	Anywhere, any time	On a phone, at the end of an appointment
Result	Months of building and no user	One person gets the outcome this weekend

And the corresponding decision on every feature:

Feature	Build it now?	Instead
Accounts and login	No, unless value is impossible without it	A link per customer
Settings	No	Make the decision yourself
Integrations	Only the one it is useless without	Export a file
Second customer type	No	Write it down for later
Billing automation	No	An invoice or payment link
Onboarding flow	No	Onboard the first ten personally

What to leave out on purpose

Accounts and login, if the value can be delivered without one. Every account system is a support burden. Settings, which are decisions you have handed to the user because you did not want to make them. Integrations, unless the product is useless without one specific integration. Anything for the second customer type, which is the single biggest source of scope creep. Billing automation, at least at first. An invoice or a payment link works for the first ten customers. Onboarding flows, because with ten customers you can onboard each one personally, and you will learn more doing it.

Cutting these is not laziness, it is a deliberate transfer of work from building to doing, and doing teaches you things building does not.

Do it by hand first

The most useful move available is to deliver the outcome manually before automating any of it.

If the product is meant to produce a weekly report, produce it yourself and email it. If it is meant to match two sides of a marketplace, do the matching in a spreadsheet and send introductions. If it is meant to monitor something, set an alarm and check it yourself.

Three things happen. You find out whether anyone actually wants the outcome, which is the only question that matters. You learn the workflow properly, which makes the eventual build far better than it would have been. And you can charge from day one, because customers are buying the result and do not care how it is produced.

The point at which manual delivery starts to hurt is the point at which you know exactly what to automate, and you will automate the right thing.

The weekend shape

Friday: decide. Write the three sentences: customer, job, situation. Write what it does not do. Write what you will do by hand.

Saturday: build the thin path. The narrowest route from a person arriving to a person getting the outcome. No settings, no accounts unless essential, no second use case.

Sunday: put it in front of one person. Not a launch. One customer, watched while they use it, with you available to fill the gaps by hand.

If Sunday is uncomfortable, that is correct. Showing something incomplete to a real user is the entire exercise, and every day you delay it buys you nothing except more code that may be wrong.

When it is not a weekend

Some things genuinely cannot be scoped this small: regulated products, hardware, anything requiring safety certification or clinical evidence, anything where a wrong answer harms someone.

Those still benefit from the same discipline, just at a different scale. Narrow the customer, narrow the job, deliver manually where you legally can, and get real usage of the smallest legitimate version before building the rest.

FAQ

What is an MVP? The smallest version that lets one real customer get the outcome they wanted. It is not a smaller version of the finished product, it is a test of whether the outcome is worth having.

How long should it take to build an MVP? Days rather than months for most software and service ideas, because the goal is a real user rather than a complete product. If it is taking months, the scope is too wide or you are building things you could do manually.

What should you leave out of a first version? Accounts where avoidable, settings, integrations, second customer types, billing automation and onboarding flows. Most of these can be handled personally for the first ten customers.

Should the MVP be automated? No. Deliver manually first. It proves demand, teaches you the workflow, and lets you charge immediately, and you will automate the right part rather than the part you guessed.

How do you know when to stop cutting scope? When one person can get the outcome. If removing one more thing breaks that, you have reached the floor.