What to cut from version one

The first version of a product is the most expensive place to be wrong, because nothing in it has been tested against a real user yet. Every feature is a guess wearing a deadline.

That is not an argument for building something flimsy. It is an argument for building fewer things properly.

The one question

For each feature on the list, ask: if we removed this entirely, would the product still do the single thing it exists to do?

If yes, it is version two. Not never. Version two.

This is harder than it sounds because most features are individually defensible. Nobody puts a bad idea on the list. The list is full of good ideas, which is exactly why it needs a rule rather than a debate.

Things that are almost always version two

Settings pages. A settings page is a monument to a decision you did not want to make. Every toggle is a branch you now have to build, test and support twice. Pick a sensible default, ship it, and add the toggle when someone actually asks.

Roles and permissions. Unless you are selling to enterprises on day one, everyone can be an admin. Permission systems are deceptively large, they touch every query you will ever write, and they are much easier to add once you know what people actually do.

Onboarding flows. A five step tour is usually a patch over an interface that needs work. If the product needs a tour, fix the product.

Your own auth. Use a provider. Nobody has ever chosen a product because it had bespoke password reset.

Analytics dashboards. Users almost never want a dashboard in version one. Founders want the dashboard. Those are different requirements and only one of them is paying you.

Things that are never version two

Some things are much cheaper before launch than after, and cutting them is a false economy.

Data model. Getting the shape of your core entities wrong is the one mistake that compounds. Renaming a button is an afternoon. Splitting a table that everything references is a quarter. Spend the time here.

Auth and access control, in the narrow sense of a user only being able to see their own data. Not roles. Just correctness. Retrofitting this means auditing every endpoint you ever wrote.

A way to know what happened. Basic logging and error reporting. Without it you will be debugging by asking users what they clicked.

Backups you have actually restored from. An untested backup is a belief, not a backup.

Scope creep has a specific shape

It rarely announces itself. It arrives as the word "just".

Can we just add a filter. Can we just make it work for teams as well. Can we just support one more file type. Each is small on its own, which is what makes the pattern so effective at destroying timelines. Nobody ever adds a month; everyone adds three days, eleven times.

The useful response is not no. It is: yes, and here is what moves. Attaching a cost to each addition turns a vague conversation into a real one, and about half the requests withdraw themselves once the trade is visible.

Ship narrow, then widen

A product that does one thing well for a small group beats a product that does eight things adequately for nobody. The narrow version is also dramatically easier to explain, which matters more than most teams expect, because a thing nobody can describe is a thing nobody recommends.

You are not trying to build the whole product. You are trying to build the smallest thing that produces real information. Everything after that is easier, because you are no longer guessing.

What this looks like in practice

When we scope a build, we produce two lists. What ships, and what is deliberately not shipping yet. The second list matters as much as the first, because it is the record that those ideas were considered rather than forgotten, which is what stops them coming back as emergencies in week six.

If you have a spec and a launch date that do not agree with each other, send them over. We will tell you which half we would build first, and why.