What We Cut From Version One, and Why It Worked

The most expensive feature is the one nobody uses

Every first version arrives at the same crossroads: the list is longer than the budget. The usual response is to squeeze — build everything, thinner. It is the wrong move, and it is the one most first-time app owners make.

We have shipped eight products of our own. Here is what we cut from two of them, and what happened.

Kvit shipped without cloud sync

A cycle tracker without an account and without sync sounds unfinished. Users change phones. They expect their history to follow.

We shipped it anyway, because sync is not one feature. It is accounts, password recovery, conflict resolution, a server holding intimate health data, a breach surface, and a privacy policy that has to explain all of it. Building it "small" is not possible; it either exists properly or it is a liability.

What shipping without it proved: the absence became the product. Local-only is why the app can honestly say your entries never leave the phone. Had we built a thin version of sync in month one, we would have spent the budget and lost the one claim that distinguishes it.

Qivvo shipped without a backend

An AI expense tracker with no server: no accounts, no dashboard, no cross-device history. Recognition runs on the device, data lands in a local database.

The cut removed a whole category of work — infrastructure, scaling, auth, uptime — and forced the interesting question earlier: *is the scanning actually good enough to be worth using?* That is the question the product lives or dies on, and a backend would have delayed reaching it by weeks.

The three questions we use

When a scope list is too long, these sort it faster than any prioritisation matrix:

1. What is the one thing this must do to be worth opening twice? Everything that does not serve it is version two — and a smaller scope is a shorter timeline. Most lists have exactly one answer and eleven distractions. 2. Which item, if we skip it, changes what the product *is* rather than what it *has*? Those cannot be cut. Everything else can. 3. What are we building because a competitor has it? That is the cheapest item to remove and the one people defend hardest.

What is worth keeping even when it is expensive

Cutting is not the same as cutting corners. Three things we do not remove from a first release:

• Anything that is hard to change later. The data model, the auth decision, whether the app works offline. These are load-bearing; retrofitting them costs more than building them.
• Store compliance. Privacy policy, data-deletion path, age rating, required declarations. Not features, not optional, and the cause of most launch delays.
• The instrumentation to know if it worked. Ship without analytics and version two is guesswork.

The uncomfortable part

A smaller version one means launching something you are slightly embarrassed by, and getting the feedback that tells you which of the cut features actually mattered. Usually it is not the ones that were argued about hardest.

That is the whole argument for scoping down: not that less is better, but that you find out sooner.