What actually belongs in your MVP

Everyone agrees the first version should be small. Almost nobody agrees on what small means, which is why MVP scoping conversations turn into negotiations over a feature list. A better starting point: an MVP is not a small product. It's the smallest thing that settles the biggest open question about your business.

Name the question first

Before listing features, write one sentence: what is the riskiest thing we believe? It might be that a particular buyer will switch from their current workaround. It might be that a process can be automated reliably enough to trust. Whatever it is, the first version exists to answer it — and every feature either helps answer it or doesn't.

This converts scope from taste into logic. "Do we need user roles?" becomes "does the riskiest question depend on multiple people with different permissions?" Sometimes yes. Usually not yet.

Things that feel essential and usually aren't

• Self-service signup, when your first ten customers will be onboarded by you personally.
• An admin dashboard, when the admin is you and the database is right there.
• Billing automation, before you know what you're charging or how often.
• Settings and configuration, which exist to avoid making a decision you should make.
• A second customer type, before the first one is proven.

Things founders cut that they shouldn't

The reverse mistake is just as common. Founders cut the parts that make the product survive contact with a real customer:

• Reliability in the one workflow that matters. A narrow product that works beats a broad one that half-works.
• The moment of first value. If a new user can't reach the point where the product is obviously useful, nothing else matters.
• Basic instrumentation. Launching without knowing what people do is launching without learning anything.
• Security and data handling appropriate to what you're storing. This is not a later problem.

Manual is a feature

Automation is expensive; people are flexible. In a first version, doing something by hand behind the scenes is often the correct engineering decision. Customers don't see the difference, and you keep the option to automate the version of the workflow that survives real use rather than the one you imagined.

The goal of the first version is not to impress anyone. It's to make the next decision obvious.

Set the time box before the feature list

Decide how long the first version gets, then fit the scope inside it. Done the other way around, scope expands to fill whatever time exists — and it always exists, right up until the money doesn't. A fixed window forces the trade-offs that produce a genuinely minimum product.

If those trade-offs are hard to make alone, that's the gap a technical co-founder fills: someone accountable for the outcome who can say what to leave out and defend it.