How to Scope a First Version That Does Not Collapse

A first version has one job: to find out whether the idea works with real people, at a cost you can afford to be wrong about. Everything else follows from that, including every argument about what goes in.

So write the question down before the feature list. Will restaurant owners actually enter their stock every morning. Will patients book online instead of phoning the receptionist they already know. Will drivers use an app instead of the group chat they use now. Those are answerable questions, and the version exists to answer one of them.

Then the rule that settles most arguments: everything in scope either answers that question or is required in order to answer it. When somebody asks for a feature, you are not judging whether it is a good idea. You are asking whether the answer changes without it.

A small version that answers nothing is not cheap, however little it cost. That is the failure that hides inside every conversation about cutting scope, and it is why the cutting has to be done against a question rather than against a budget.

Pick the single sequence a person follows to get value from the product, from the first screen to the moment something useful has happened. Sign up, do the thing, get the result. That sequence is the spine, and it cannot have a gap in it anywhere.

Everything else is a branch. Branches can wait, be done by hand, or be missing entirely, and the product still works for the person walking down the spine.

Take a delivery app for a bakery. The spine is: the customer picks items, pays, the bakery sees the order in time to make it, the driver gets an address, and the customer knows it is on the way. Remove any one of those and the whole thing stops being a product. Loyalty points, ratings, saved addresses, scheduled orders, a referral scheme, order history: every one of those is a branch, and every one of them will be argued for as essential by somebody.

Write the spine as a numbered list of steps on a single page and put it on the wall. When a new feature is proposed, the question is whether it is on that page. If it is not, it goes on a list and gets decided after launch.

There is a set of unglamorous things that always get cut and always come back as an emergency in the second month. They are worth defending specifically, because they never survive a general instruction to trim.

What happens when things fail. The payment declines. The phone has no signal halfway through. The server is down. A first version where failure is simply undefined does not save you money, it converts engineering work into support work, and support work is more expensive and lands on people who cannot fix the cause.

The ability to see what is happening. Basic analytics and crash reporting are not a nice extra here. Without them you cannot answer the question the version was built to answer, and you will spend the following quarter arguing from opinions in a meeting room instead of from what people actually did.

And the small mercies. A working password reset, because people forget passwords on day one. Enough security to not embarrass yourself: proper authentication, no secrets buried in the app, personal data stored the way the law where you operate requires. Plus a way for a confused person to reach a human being, which for a first version can be an email address and somebody who reads it.

The admin panel. This is the biggest single saving available and almost nobody takes it. In the first months you have few enough customers that your own team can do the administration directly against the data, or through a spreadsheet, or by asking a developer. Building screens so your staff can do something a handful of times is a poor use of the budget.

Settings and preferences. Every toggle is a decision you have avoided making, plus two paths through the code that both need testing forever. Pick the behaviour you think is right and ship it. If people complain, you have learned something specific, which is worth more than the setting.

Roles and permissions beyond what actually exists on the first day. Teams routinely build an elaborate permission model for an organisational structure their customers do not have yet, and then have to unpick it when real customers turn out to be organised differently.

And the long tail: onboarding tours, notification preference screens, dark mode, a second language, data export, a public interface for other developers, a web version alongside the app, and anything at all built for a type of customer you do not have. Each is defensible on its own. Together they are the reason first versions take a year.

The most useful trick in this whole business is to do by hand anything that is expensive to automate and cheap to do manually, at least until the volume makes it painful.

Matching drivers to jobs by having somebody look at a screen and decide. Approving new sellers by reading their form and emailing them. Sending the weekly summary by writing it. Checking a document by opening it. All of these are hours of a person's time and weeks of a developer's, and in the first months you have the hours and you do not have the weeks.

What you get in return is worth more than the saving. Doing it by hand teaches you what the rule actually is. Teams who automate first almost always automate the wrong rule, because they wrote it from a guess, and then the automation has to be unpicked once real cases arrive. The person doing it manually for a month can tell you the exceptions nobody predicted.

The limit is real and you should name it in advance. Manual works until a volume, and beyond that it fails suddenly rather than gradually. Decide roughly where that point is, watch for it, and start building the automation before you reach it rather than after somebody has been working weekends for a month.

This is the section that gets skipped, and it is the reason first versions fail. Some cuts reduce scope. Others remove the reason anybody would use the thing at all, while looking exactly like a sensible saving on a spreadsheet.

Cutting the thing that makes it faster than what people do now. If your app takes longer than the message they currently send on WhatsApp, no amount of design saves it. Whatever the product replaces sets the bar, and the bar is usually lower and harder to clear than anybody expects, because the existing way is already familiar and free.

Cutting trust where trust is the product. A marketplace with no verification, no ratings and no way to complain is just a list of strangers with your money in the middle. If people are handing over money or letting somebody into their house, the parts that make that feel safe are the product, not a phase two.

Cutting speed and reliability. Users forgive missing features easily and readily. They do not forgive a form that loses what they typed, an app that takes an age to open, or a payment they are not sure went through. Those produce uninstalls rather than feedback, which means you do not even learn why.

And cutting until it serves nobody in particular. It is far better to do everything one type of customer needs than a third of what five types need. A narrow product that works completely gets used and talked about. A broad one that half works gets opened once.

There is a second failure mode, and it is the opposite one. The first version works, people want more, and it turns out nothing can be added to it without starting again. Then the thing you learned goes into the bin along with the code.

A few things are worth doing properly even in a rushed first version. How the data is shaped, because you will have real customer data in that shape and reshaping it later is a migration with real risk. Authentication, because retrofitting it is horrible and getting it wrong is a security incident. And the boundary between the app and the server, because a clean one lets you replace either side without touching the other.

Plenty of other things can be scrappy without any long term cost. The admin, the styling of internal screens, one off scripts, anything a person does by hand, reporting that gets read once a week. Nobody outside the team ever sees them and rewriting them is cheap.

The rule to hold in your head is about where shortcuts are recoverable. A shortcut in what users touch is cheap to fix later, because you just build the better screen. A shortcut in how data is stored is expensive forever, because by then it is full of real records that people care about.

Scope does not grow through bad decisions. It grows through a series of reasonable requests, each individually small, each from somebody with a point, spread over enough weeks that nobody sees the total.

The mechanism that works is boring. One named person decides what is in, and everything new goes onto a written list that gets reviewed after launch rather than into the build. The list is genuinely useful, because after launch it turns out that half of it was solving a problem real users do not have.

Fix the date rather than the feature list. When something has to give, and something always does, it should be obvious in advance which one it is. Teams that fix both end up shipping something poor on time, which is the worst of the available outcomes.

One last honest thing. Sometimes the first version answers the question with a no. People do not want it, or they want something adjacent, or the workflow you designed for is not the one they have. That is the cheapest possible outcome and the entire reason for keeping it small. Teams who cannot bear that answer build a large version one instead, and then they find out the same thing a great deal later, having spent everything.