What Belongs in an MVP, and What Is Quietly Killing Your Budget

Write down the question first

Before scoping anything, write one sentence: we believe that [these people] will [do this thing] because [this reason]. That sentence determines what belongs in the build. Anything that does not help you observe whether it is true is phase two.

Teams that skip this end up building a small version of the whole product rather than a sharp test of the risky assumption, and small versions of everything are the most expensive way to learn nothing.

The six things that almost always wait

1. An admin panel. For the first fifty users, a developer running a query is faster to build and adequate.
2. Settings and preferences. Pick sensible defaults. Every toggle is a branch to build and test.
3. Role hierarchies. One role until you have evidence a second is needed. Permissions multiply work faster than any other requirement.
4. Self-service billing tiers. Invoice the first customers manually. It is also better research.
5. Integrations. Build the one that unblocks adoption. The other four are marketing copy for now.
6. Onboarding automation. Onboard early users personally. You will learn more in those calls than in any analytics dashboard.

What must be in it

The core workflow, end to end, actually working. Authentication, because you need to know who did what. Enough instrumentation to see whether people complete the workflow. And a way for users to tell you something is wrong.

The single most common MVP mistake is a beautiful onboarding flow leading to a core feature that only half works. Users forgive rough edges around the thing; they do not forgive the thing.

Manual behind the curtain is legitimate

If the hard part of your product is a process, run it by hand at first. The customer sees a form and receives a result; behind it, a person does the work. This is not cheating — it is the cheapest possible test of whether the result is worth paying for.

It also produces exactly the training data and process detail you need to automate later, and it forces you to learn the workflow properly before encoding it.

Realistic budgets

If the first band feels small for your idea, that is usually a signal the idea has not been narrowed enough yet rather than that the band is wrong.

Decide the kill criteria before you build

Write down what result would make you stop. “If fewer than 15 of the first 50 users complete the core workflow twice, we stop and rethink.” Deciding this in advance is the only reliable protection against sunk-cost reasoning.

Teams that do this are noticeably calmer when the data arrives, because they are checking against a decision rather than negotiating with themselves.

Frequently asked questions