What to Leave Out of Your First App Version

Every scoping guide tells you to sort features into must-have and nice-to-have. Nobody has ever finished that exercise honestly, because everything you thought of feels like a must-have or you would not have thought of it.

There is a better question, and it has an actual answer: if I skip this now, how expensive is it to add later? Features that are cheap to add later should always be cut. Features that are expensive to retrofit should be decided now even if they do not ship now. That reframes scoping from a taste judgement into a structural one, which matters more when an AI builder will happily generate whatever you ask for in an afternoon.

The reversibility test

For each feature, ask what adding it in three months would require:

That middle band is the one people get wrong. It is not a question of whether you build the feature, it is whether your data model can accommodate it without a rewrite. Deciding that teams will exist eventually costs you one nullable column today and saves a migration across every table later. Actually building teams costs you weeks.

Four things that are expensive to retrofit

These are the ones worth deciding on day one, whether or not you build them.

Who owns a row

Single user, or user inside an organisation. Retrofitting the second onto the first means revisiting every query in the application, and an AI builder will not warn you, it will simply generate the single-user version because that is what you asked for. Multi-tenancy in an AI-built app is far cheaper as a decision than as a migration.

Whether anything is deleted

Hard delete or soft delete. Once real deletions have happened, no later decision can bring the rows back, and the first customer who deletes the wrong thing will ask. A deleted_at column costs nothing now.

Whether history matters

If anyone will ever need to know what a record looked like last month, that has to be captured as it happens. History cannot be reconstructed after the fact. Most apps do not need it. The ones that do, need it from the first write.

Identity

Email and password now, single sign-on later is fine, provided accounts are keyed on something stable rather than the login method. Merging two accounts that turned out to be the same person is one of the least pleasant migrations there is.

Everything on that list is a consequence of the data model, which is why planning your data model before you build is the step that makes this whole exercise short.

What to cut without hesitating

By the same test, these are almost always additive, and almost always the things people build first because they are satisfying:

• Settings pages. Every setting is a decision you could have made for the user. Ship the opinionated default.

• Admin dashboards for yourself. Query the database directly until the tedium is genuinely costing you an hour a week.

• Onboarding tours. You cannot design a tour for a product nobody has used yet.

• Notification preferences. Ship one notification, no preferences. Preferences arrive when someone complains.

• Anything responding to a scale you do not have. Bulk import matters at fifty customers, not five.

• A second user role. Two roles is four times the permission logic of one, and most first versions have exactly one kind of user.

The pattern is that these features cost real time and are all pure additions later. Cutting them is free in a way that cutting a structural decision never is.

The version that actually teaches you something

A first version exists to answer a question you cannot answer by thinking. Write the question down before you scope: will people book through this rather than phoning, will anyone finish the setup, will they come back on the second day.

Then cut everything not required to answer it. This is a sharper filter than any feature list, because a feature that cannot change the answer is not part of the experiment, and it makes the go-live decision concrete rather than a feeling that it is nearly ready.

Two things people mistake for scope creep are not. Making it work on a phone is not a feature, it is a condition of anyone using it. And the empty state, what a new user sees before there is any data, is the first thing every user sees; skipping it is the most common reason a good first version reads as broken. Nielsen Norman Group's write-up on empty state interface design is the short version of why a blank screen with no explanation costs you more users than a missing feature ever will.

None of this is specific to AI builders, but the failure mode is sharper with one. When adding a feature takes ten minutes, the discipline has to come from you rather than from effort, which is one of the honest limitations of ai app builders. The same restraint applies before you start, in validating an ai product idea before building it, and after, when the first version teaches you what the second should contain. The overall path is covered in how to build an app with ai.

Once this version is live, the discipline shifts from cutting features to getting it in front of people who are not you. How to find your first beta testers for an AI-built app covers where to look for that first round.

FAQ

How small should a first version be?

Small enough that one person can hold all of it in their head, and large enough to answer the question you wrote down. If you cannot describe it in three sentences, it is still too big.

Is it worth adding authentication in version one?

Only if the app is useless without it. Plenty of first versions work with a shared link. What matters is that whatever you build keys records to a stable identity, so adding logins later is not a data migration.

What if I cut something and a customer asks for it immediately?

That is the exercise working. A request from a real user is far better information than your guess, and building it then takes the same time it would have taken before, unless you cut a structural decision instead of a feature.

Does this change when an AI builder generates the code?

The list does not change; the temptation does. Cheap generation makes it easy to accumulate features nobody asked for, each with its own maintenance cost, so the reversibility test matters more rather than less.