What a first version actually is, and what it isn't

Almost every first conversation I have includes the words "let's just start small". Then the feature list arrives and it is a complete product with the polish removed. Those are different things, and confusing them is the single most expensive mistake I see.

A first version is an experiment, not a discount

A first version exists to answer a question you cannot answer by thinking harder. Will people book through a link instead of calling? Will drivers actually use the app? Will anyone pay for this? A first version is the cheapest honest way to find out.

That reframes the whole scoping conversation. The question stops being "what can we afford to build?" and becomes "what is the least we can build that would change our mind?" Those produce very different feature lists.

Cheap versions of everything is the failure mode

The tempting move is to keep all fifteen features and build each one to 40%. It feels fair — everybody's favourite thing survives. It is also the reliable way to produce something nobody wants to use, which teaches you nothing except that the thing was bad, when in fact only the execution was.

Two features that work properly beat fifteen that half work. If a feature is in, it should be good enough that its failure means something.

How to actually cut the list

Go through the features and ask one question of each: if this were missing on day one, would a real user walk away? Not "would they complain" — complaints are fine, and are useful data. Would they stop using it.

• Login with email, phone, Google and Apple — pick one. You can add the rest in an afternoon once people are actually signing up.
• An admin panel to edit everything — start with the three things that change weekly. The rest can be a database change for now.
• Notifications on every event — pick the one that brings someone back to the product.
• Analytics dashboards — you have almost no data yet. A spreadsheet export is enough for months.

The part people skip

A first version is only worth building if you have decided, in advance, what you will do with the answer. Before I start, I ask what number would count as working and what would count as failed. If there is no answer, we are not building an experiment — we are just building a small product, and we should be honest about that instead.

The point of shipping early is not to save money. It is to stop spending money on the wrong thing sooner.

What this looks like in practice

The booking system in our examples runs six to eight weeks. It has a calendar, a public booking link, reminders and optional deposits. It does not have inventory, payroll, a loyalty scheme or a customer app. Not because those are bad ideas — because by the end of it the owner knows whether customers will book online at all, and every one of those features would be designed better with that answer in hand.

If it works, you build the next thing knowing something. If it does not, you found out for the price of a month rather than the price of a year.

How long a first version should take

There is no universal number, and anyone who gives you one before hearing the feature list is quoting a habit rather than your project. A booking page and a multi-tenant subscription product are not the same exercise. Ask for the features and the timeline together: if the second does not follow from the first, one of them is fiction.

Most of the weeks collect in a few specific places. Anything that has to work offline and reconcile later. Anything that takes money. Anything that has to keep one customer walled off from another. Anything on two app stores rather than a browser. And anything that waits on somebody else — a store reviewer, a payment provider, photographs nobody has taken yet. Two features that read alike on a list can differ by a month once you ask which of those they touch.

When nobody can say which features the months are for, the familiar things go wrong. The market you were testing has moved. The team has become attached to the thing and will interpret ambiguous results generously. And the cost has grown large enough that admitting it did not work has become expensive in a way that has nothing to do with money. What protects you is not a deadline; it is a feature list short enough that every item earns its place, and a timeline you can read back feature by feature and see where the weeks went.

What happens after — the part nobody plans

Most first-version conversations stop at launch, which is roughly like planning a wedding and not a marriage. Three things follow and all three should be agreed before the build starts.

1. Who watches it? Someone has to look at what users actually do, daily, for the first fortnight. If nobody owns that, you have bought a product and not an experiment.
2. What is the decision date? A day, in the calendar, when you look at the numbers and decide continue, change or stop. Without one, first versions drift into being the product by default.
3. Who fixes it? Real users find real bugs in week one. If there is no arrangement for that, the experiment dies of neglect and you will wrongly conclude the idea failed.

The first version that should not be built

Sometimes the honest advice is not to build software at all, and a developer who never says this is a supplier rather than an adviser.

If the question is whether people want the service, you can often answer it with a landing page and a phone number for a fraction of the cost. If the process is not yet settled, software will freeze a bad version of it in place. If nobody has ever done the job manually, you do not yet know what to automate — do it by hand for a month, badly, and build the thing you learn you needed.

I have talked people out of builds on this basis. It costs me the project and it saves them a year, which is a trade I am comfortable with, because the ones who come back are the ones worth working for.

A short checklist before you commit

• Can you write down, in one sentence, what this will tell you?
• Do you know what result would make you stop?
• Is there a real person who will use it in week one, by name?
• Does the timeline follow from the features, item by item?
• Have you removed everything that would not change the answer?

Five yeses and it is worth building. A no on the first two means the conversation is not finished, and building anyway is how budgets disappear into things nobody can evaluate.