What to build first in an MVP

The phrase "minimum viable product" has been stretched so far that it now means almost nothing. To some founders it means a cheap version of the full idea. To others it means an unfinished, embarrassing prototype. Both readings lead to wasted money, because both treat the MVP as a smaller version of the destination instead of the fastest way to learn whether the destination is worth reaching.

A more useful definition: an MVP is the smallest thing you can build that answers your riskiest question with real behavior. Every idea rests on an assumption that, if wrong, makes the rest pointless — people will pay for this, providers will show up, patients will actually use the link. The job of the first build is to test that assumption with real users as quickly and cheaply as honesty allows.

Most products have one core loop — the repeating sequence that delivers the value you promised. If users can complete that loop and get the outcome, the idea has a pulse. If they cannot, no amount of polish elsewhere will save it. So the first thing to build is that loop, end to end, and almost nothing else.

The loop is usually three or four steps. For a marketplace it might be request, match, respond. For a clinic tool it might be book, remind, confirm. For an internal operations app it might be submit, review, complete. Write your loop as a single sentence. If you cannot, the product is not yet clear enough to build, and that clarity is the cheapest thing to fix.

Some features exist to deliver value. Others exist to make the product feel complete — and those are the ones that quietly consume an MVP budget. Settings pages, role management, analytics dashboards, onboarding tours, and admin panels all feel necessary, but they rarely answer your riskiest question. They make the product look like a real company built it, which is a poor use of money you do not yet know is justified.

A simple test for any proposed feature: does it help a user get through the core loop for the first time? If yes, it might belong in version one. If it only helps after someone is already a happy, regular user, it is almost always a version-two feature. The first release should be easy to explain in a sentence, easy to put in front of a stranger, and easy to change the week after you learn something.

The cheapest features in an MVP are the ones you do not build at all. Many steps that look like they need software can be handled manually behind the scenes while you learn. If matches in your marketplace can be made by a human reading requests for the first month, you save weeks of engineering and learn exactly what a future algorithm would need to do.

This is sometimes called a concierge approach: the user sees a smooth experience, while a person does the hard part by hand. It feels unscalable because it is — and that is the point. You are buying information, not scale. Once you understand the rules a human applies, automating them is straightforward. Automating rules you have not yet discovered is how budgets disappear.

The real output of an MVP is not the software. It is evidence: do people understand the offer, where do they drop off, what do they email you asking for, which part of the promise do they actually value, and what are staff quietly doing by hand to keep things working? A first version that produces these answers in three weeks is worth far more than a polished build that takes six months to tell you the same thing.

Plan the MVP with the next decision in mind. Before you start, write down what result would convince you to invest more, what result would make you change direction, and what result would tell you to stop. Deciding this in advance protects you from the most common trap in early products: building more because it is easier than admitting you have not yet proven the idea.