MVP vs full product: what founders should build first

Most founders should build an MVP first: the smallest product that delivers the core value to a real user, built properly. Not a prototype held together with tape, and not a quarter of every feature, but all of one thing. The exceptions are real, and we will get to them, but the default is clear, because the most expensive thing a founder can buy is a year of building the wrong product thoroughly.

The trouble is that MVP has become a word people say while building a full product anyway. The scope creeps one reasonable feature at a time, each defended with a plausible sentence, until the minimum product needs a year and the viable part has quietly left the room. Scope discipline is not a technique. It is a fight, and this post is the way we fight it with founders every month.

An MVP is a learning instrument, not a discount product. Its job is to answer the question your company is a bet on: will these people use this thing, pay for it, and come back. Everything in the build either helps answer that question or delays the answer, and there is no neutral category. Every feature you add before launch is a week you spend not knowing whether the bet is right.

This reframing does most of the work. Founders argue endlessly about whether a feature is important, because almost everything is important eventually. They argue much less about whether a feature is needed to answer the question, because most features obviously are not. The roadmap does not disappear. It just stops being a launch requirement and becomes what it should have been all along: a list of things the answer will reorder.

Cut whole audiences before you cut depth. A product for one kind of user is dramatically cheaper than a product for three, because every audience brings its own screens, permissions, and edge cases. Pick the user whose behaviour answers the question and serve only them. The others are not being abandoned, they are being sequenced.

Cut everything a human can do behind the curtain. Onboarding emails can be sent by hand. The admin dashboard can be a database query. Billing edge cases can be handled by you, personally, apologising warmly. At MVP scale, manual is not a compromise, it is a feature: you learn more from doing the operations yourself for a month than any analytics screen will ever tell you.

And cut the configurable version of everything. Settings pages, themes, preferences, role management: each one doubles the states your product can be in, and at this stage every user should be having nearly the same experience anyway, because that is what makes their feedback comparable. Opinionated defaults are cheaper than options and usually better.

Never cut the reliability of the core journey. The MVP earns its answer only if the one thing it does works every time a stranger tries it. A payment that fails, a save that loses work, a signup that breaks on a real phone: any of these poisons the experiment, because users cannot tell the difference between an idea that is wrong and a build that is broken, and they do not stay long enough to help you tell it apart either.

Never cut the data model thinking either. Screens are cheap to change and foundations are not. An MVP built on a data model that vaguely matches the business can absorb the pivots that are coming. One built on a weekend's assumptions becomes the rewrite you pay for in your second year. This is the difference between building less and building carelessly: the first is strategy, the second is debt with a launch party.

When you are replacing a system a business already runs on. An operations platform that does half of what the spreadsheet does is not a minimum version, it is a worse tool, and the team will be right to reject it. Here the honest minimum is one complete workflow moved end to end while the old system keeps running, which is a different and larger thing than a classic MVP.

When trust is the product. In healthcare, in anything touching money movement, in tools people bet their operations on, the first impression is close to unrepeatable, and the compliance work is not optional garnish. You can still scope hard, one clinic instead of ten, one specialty instead of all, but the slice you ship must be finished to a standard the word minimum does not suggest.

And when the question is already answered. If validated demand exists, if customers are waiting, if you are porting a proven product to a new market, then learning is not the bottleneck and speed to a complete product is. Building deliberately small when nobody needs convincing is not discipline. It is just slow.

Write down the riskiest assumption in your plan, the one that kills the company if it is false. If a smaller product can test it, build the smaller product, and let the result spend your remaining money. If the assumption is already tested, or if a small product cannot generate a fair test, build the complete thing for the narrowest slice of market that constitutes a real launch.

Then defend the scope in writing. A one-page document that names the single user, the single journey, and the question the launch must answer, plus an explicit cut list of everything deferred and why. When the reasonable feature requests arrive, and they arrive weekly, the argument is with the page instead of with each other. It is the cheapest project management tool ever invented.

Build an MVP when the core bet is unproven, and make it the smallest product that delivers the core value completely and reliably to one kind of user. Cut audiences, admin polish, settings, and anything a human can do by hand. Never cut the reliability of the core journey or the care in the data model. Skip the MVP and build a finished slice when you are replacing a system a business depends on, when trust and compliance define the product, or when the demand is already proven. The scope should be decided by the question you need answered, never by the length of your feature list.