My co-founder and I sat down a few weeks before our own launch to argue, politely, about what was actually going in the MVP. I was pushing hard for a gamified credits system. Instead of every new user getting a flat twenty credits at sign up, they would start with ten and earn more as they used the app to expand their idea.
I liked it because it was clever. He liked it less, because it was not the thing anyone was paying us for. We went back and forth for the best part of an hour. In the end we cut it. The MVP shipped with a flat credit allocation and nothing else clever bolted on. The gamified version went onto an ideas board, where it has been joined since by a long list of suggestions from friends and other founders who have tried the product and told us what they wanted next.
That argument is the one every founding team has, in some form, in the weeks before launch. The pull to add is enormous. The discipline to cut is what gets the thing out of the door.
The short answer
An MVP should contain the smallest thing a real person will pay for, plus the few unglamorous bits that make it safe to put in front of them. Nothing else earns a place yet.
What actually belongs in the first version
Think of an MVP the way a chef thinks about opening a small restaurant. You are not trying to print every dish you might ever cook. You are trying to serve one table well enough that they tell their friends. That gives you four categories.
The one thing the customer is paying for. Name it in a single sentence. If you cannot, the MVP is not ready to scope — the thinking is. For a holiday-let booking tool, it might be "a host can take a paid booking from a guest without phoning their bank". For a compliance tool, it might be "an SME can produce a defensible record of who accessed what". Everything else in the build is in service of that sentence.
The path the customer walks to get there. From the moment they land on the site or app to the moment they have the outcome they paid for. Every screen on that path earns its place. Every screen off it does not, yet.
The unglamorous safety bits. Login that actually keeps people out of each other's accounts. A way to take payment that does not store card numbers on your own server. Backups. Basic logging so you know what happened when something breaks. A privacy notice that reflects what you are really doing with the data. None of this is exciting. All of it is what separates a product from a prototype.
The way you will hear from the first ten users. An email address that gets read. A simple form. A Calendly link. Founders forget this one constantly and then wonder why the early feedback is silent.
That is the MVP. Settings pages, profile photos, dark mode, in-app onboarding tours, integrations with tools your customer has not asked about — all of it can wait.
What we see in the wild
Two patterns we have watched cost founders months.
The first is the founder who builds the admin panel before the product. By the time they show us what they have, there is a beautiful internal dashboard for managing users, resetting passwords, and viewing activity logs. What is missing is a clear answer to what a user actually does on day one. The admin panel got built first because the founder is a user of it — they know exactly what they need. Focus first on what a real, paying customer wants, unpredictable as that is, especially now that it is fast to add working features safely.
We have done a version of this ourselves. In the first four months after starting our business, we built a security assessment tool to run our own client engagements. It was sharp, well-engineered, and made our work faster. At some point we looked at it and thought: we could offer this to clients directly. The problem was that it had been designed entirely around our workflow, not theirs. Adapting it for external use took longer than building it had. We had built the right tool for the wrong user. So be careful at the points where you pivot, and remember to cut back.
The second is the founder who builds the second version of the product first. They had a genuinely interesting idea, spent a few weeks studying competitors, and ended up building the thing those competitors took three years and several rounds of funding to arrive at. The feature set is technically impressive. The differentiation is not there. Nothing connects back to a specific conversation with a real buyer — a person who said out loud that they needed this, that they had tried other things, and that none of them worked.
The product is commercially silent because it was built for an imaginary customer shaped like the competitor's roadmap rather than a real one shaped by actual frustration.
Both examples are from clever, hard-working founders. Both got to launch and found that the market did not care in the way they had expected.
The fix is the same in both cases: go back to the sentence. One sentence, one user, one outcome they will pay for. Then check that what you are building is the path to that outcome, not the infrastructure around it.
The 60-second self-check
Read these five questions out loud. If any answer is no, the scope is still too big.
- Can you describe what your MVP does in one sentence, without using the words "platform" or "solution"?
- Could a stranger get from your landing page to the paid outcome in under five clicks?
- If a customer signed up tonight, would their data be safe from other customers signing up tomorrow?
- Do you know exactly how the first ten users will tell you what is wrong with it?
- Is there at least one person who has said, in writing, that they would pay for this if it existed?
If you answered yes to all five, stop scoping and start building. If you answered no to any of them, the next hour is better spent on that than on another feature.
One last thing
We launched without the gamified credits. The flat allocation went in, the ideas board filled up, and the feedback we got from the first paying users was not about credits at all — it was about things neither of us had thought to argue over. The clever loop I had fought for might still earn its place one day. It will do so on the back of evidence, not instinct.
That is the whole point of an MVP. Not to be impressive. To be wrong quickly, in front of someone who is willing to pay you to be right.
If you want to talk this through against your own scope, you can run it past an engineer in 30 minutes.