What to cut from the first version of your app

Every founder has heard that the first version should be small. It is good advice, and it is almost useless on its own, because it does not say which things to leave out. So the list gets trimmed by instinct, the cuts land on whatever nobody defended in the meeting, and the first version ships without the one thing that would have told you whether the product works.

Cutting well is not about doing less. It is about deciding what the first version is for.

Start with the one question the first version must answer

A first version exists to learn something you cannot learn any other way. Usually it is one of these:

• Will people use it? You need the core loop, the thing a user comes back to do, working end to end.
• Will people pay for it? You need the core loop and a real way to take money.
• Will this operation work at scale? You need the back office: the admin tools, the reporting and the unglamorous screens the team runs the business from.

Write your question down in one sentence. Every feature on the list now gets judged against it, not against how nice it would be.

The test for every feature

For each item, ask: if this is missing, can we still answer the question?

If yes, it waits. That includes things that feel essential:

• Social login. An email or phone sign-in answers "will people use it?" just as well.
• Notifications beyond the critical one. Keep the message that brings users back to the core loop. The rest can wait.
• Settings screens. Pick sensible defaults and learn which ones people actually want changed.
• A second user role. Two roles is not twice the work, it is closer to three, because every screen now has to ask who is looking at it. If the second role can be handled manually by your team for the first months, do that.
• Analytics dashboards for your own team. A spreadsheet export answers the same questions until volume makes it painful.

If the answer is no, it stays, even if it is boring. A marketplace with no way to resolve a failed order has not tested whether the marketplace works.

What you should never cut

Some things look optional and are not, because adding them later costs far more than building them now:

• The language decision. If the product will ever be bilingual, especially Arabic and English, the layout has to be built for it from day one. Retrofitting right-to-left support is close to a rebuild.
• The data model for things you will definitely have. You can skip the screen for a feature, but if the records it needs are certain to exist, store them properly from the start.
• Security basics. Proper authentication, sensible permissions, encrypted connections. None of these are features, and all of them are expensive to bolt on after users trust you with data.
• A way to see what broke. Crash reporting and error logs cost almost nothing to add early, and without them the first version teaches you much less.

Manual is a feature

The most useful cut is replacing software with a person. Refunds approved by email. Onboarding done on a call. A weekly report compiled by hand. None of that scales, and it does not need to yet. Doing it by hand also shows you exactly what the automated version has to do, which is information you would otherwise have guessed at.

The rule of thumb: automate the thing users touch, and keep manual whatever only your team touches, until the volume forces your hand.

Write the "later" list down

Cuts are only painless if they are visible. Keep a second list, the version-two list, and put every removed feature on it with one line explaining why it waited. That list does three jobs: it keeps the conversation from reopening every week, it tells whoever builds version two where to start, and it turns "we dropped it" into "we scheduled it", which is much easier to agree to.

The first version is not the product. It is the cheapest honest answer to your most important question. Everything that does not help answer it can wait its turn.