What should you actually build in an MVP?
Published: Oct 21, 2026 · Last updated: Oct 21, 2026
Building an MVP is not about building a smaller version of your product. It is about building the cheapest thing that proves or kills the one assumption your business depends on, while the few parts that touch money, data and trust are engineered properly.
If you are a founder or business owner with a long feature list, a launch date in your head and a quiet worry that you are about to spend months on the wrong thing, this is for you. You have probably been told to “cut features” already. That advice is right but useless on its own, because it never tells you which features to cut.
This guide gives you a different starting point. You begin with the single assumption that could sink the business. Then every feature on your list goes into one of three buckets: build properly, fake by hand or skip. A short list of things never goes in the fake bucket, and we name them below.
The goal is a product that answers one question clearly, not ten questions badly.
Why do most MVPs end up testing the wrong thing?
Most MVPs test the wrong thing because the feature list is written before anyone names the riskiest assumption. The team scopes what the finished product will need, then trims from the bottom. What survives is a thin slice of everything, and none of it is sharp enough to prove anything.
There is a second cause. Founders tend to build what is comfortable to specify. Dashboards, settings pages, onboarding tours and admin panels feel like progress. The uncomfortable part, the moment a stranger decides whether your product is worth their time or money, gets the same attention as the settings page.
The third cause is technical. Many teams treat “MVP” as permission to build everything quickly and loosely. That works for screens nobody depends on. It fails for anything that stores data, controls access or moves money, because those parts cannot be rewritten later without breaking things for the people already using them.
So you end up making two mistakes at once. Too much effort goes into features that test nothing, and too little goes into the foundations that cannot be redone.
What does it cost when your MVP tests the wrong thing?
When an MVP tests the wrong thing, you get an answer you cannot use. Low signups could mean the idea is weak, the pricing is off, the onboarding is confusing or the core action is broken. You cannot tell which, so you cannot decide what to change.
That ambiguity is the real cost. Founders in this spot usually do one of two things. They keep adding features in the hope that one of them fixes the numbers, or they abandon an idea that might have worked with one change.
Foundation mistakes cost you in a different way. A user who loses their data in your MVP does not come back for version two. A login built in a hurry becomes the hole someone walks through. A payment flow that charges twice or fails silently produces refunds, support tickets and chargebacks before you have found product market fit. And if the data model is wrong, every feature you add sits on top of it, so the eventual rebuild grows with every week you wait.
None of this looks dramatic on day one. It shows up three months in, when you have users, a little traction and no time to rebuild the base.
If you are not sure whether your plan or half-built app already has this problem, that is exactly what a second pair of eyes is for.
Do you even need to build software for your MVP yet?
If you have not confirmed that anyone has the problem you are solving, you probably do not need software yet. Talk to twenty potential buyers, run a landing page with a clear offer, or deliver the service by hand with spreadsheets and email. None of that needs a development partner.
The same goes for a simple site with a waitlist, or a no-code setup stitched together from forms and automations that nobody pays for yet. Build that yourself. It is faster, and you will learn more doing it.
You need proper engineering when real people will trust the product with their data, their login or their money, or when the core action is technical and cannot be done by hand. That is where the rest of this guide matters.
How do you find the one assumption that could sink the business?
Write down every assumption your business depends on, then ask which one, if false, makes the rest irrelevant. That is your riskiest assumption, and your MVP exists to test it. It is usually about behaviour: will this specific person do this specific thing, more than once, and pay for it?
Try finishing these sentences honestly:
• Demand: “Customers have this problem badly enough to change how they work.”
• Value: “Our way of solving it is clearly better than what they do today.”
• Willingness to pay: “They will pay for it, not just praise it.”
• Feasibility: “We can deliver the core result reliably.”
• Reach: “We can find these customers without spending more to win them than they are worth.”
Now ask what evidence you already have for each one. Friendly conversations count for little. Someone who already pays for a worse solution counts for a lot. The assumption with the weakest evidence and the biggest consequence is the one to test first.
Then write your MVP's single question in one line. For example: “Will clinic managers upload their weekly rota and act on the staffing gaps we flag?” Every feature now has to justify itself against that sentence.
Decision rule: if the riskiest assumption is about demand or willingness to pay, most of your MVP can be faked. If it is about feasibility, the core engine must be real and almost everything around it can stay manual.
Build properly, fake by hand or skip: sorting every feature
Put every item on your feature list through three questions, in this order. Does the riskiest assumption depend on this feature working for real? Does it touch data integrity, access, money or the core user action? Could a person do it by hand behind the scenes for the first few dozen users?
Build properly if the answer to either of the first two questions is yes. These parts are few, but they get real engineering: tests, error handling, logging and a data model you would be happy to keep for years.
Fake by hand if users need the outcome but not the automation. This is often called a concierge or Wizard of Oz approach. Typical examples:
• Matching or recommendations done by you in a spreadsheet and delivered by email
• Weekly reports put together manually and sent as a PDF
• Onboarding done on a call instead of a guided product tour
• An AI feature where a person checks every output before it goes out
• Admin tasks done in the database console or a basic internal tool
Skip anything that neither tests the assumption nor protects trust. Usually that means:
• Custom settings and preferences
• User roles beyond the two you actually need
• Native apps on both platforms when a responsive web app would answer the question
• Analytics dashboards for your users
• Integrations nobody has asked for by name
• Themes, dark mode and polish on secondary screens
The trade-off to watch: faking spends your time instead of development time. That is a good trade for the first few dozen users and a poor one at a few hundred. Decide in advance what would trigger automating each faked feature, and let usage tell you which one earns it first.
If you are building a subscription product, our SaaS MVP guide covers the SaaS specific pieces such as trials, plans and tenant setup. This article stays on the sorting decision itself.
What can never be faked in an MVP, even on day one?
Four things go in the build properly bucket whatever your assumption is: data integrity, authentication, payments and the core user action. In these areas a shortcut does not just look rough. It breaks trust you cannot win back.
Data integrity. Every record a user creates must be saved once, saved correctly and be recoverable. That means a real database with constraints, not a spreadsheet behind an API, plus automated backups you have restored at least once. How to spot trouble early: if nobody can explain how a deleted record would be recovered, it would not be.
Authentication and access. Use a proven auth provider instead of a hand-rolled login. Every request should check who the user is and what they may see on the server, not only in the interface. The warning sign is an ID in the URL that, when changed, shows someone else's data.
Payments. Use a payment provider's hosted checkout or official SDK, and handle webhooks so a repeated or failed event never charges twice or grants access that was not paid for. If you are building on an AI app builder, our guide to Lovable and Stripe payments shows where these flows usually break.
The core user action. This is the one thing your product exists to do: submit the claim, book the slot, send the quote, track the vehicle. It must work every time, quickly, on the devices your users actually carry. Everything around it can be manual. This cannot, because it is the very thing your MVP is measuring.
One more item is easy to forget: error tracking and logging. Without it, you will not know the core action is failing until a user tells you, and most users never do. Our web app production readiness checklist covers the rest of the minimums.
What should you ask a team before they build your MVP?
Ask these before anyone writes code. The answers show whether the team understands the difference between an MVP and a cheap build.
• “What is the one question this MVP answers?” If they cannot repeat it back, they are building features, not a test.
• “Which parts are you building properly and which are throwaway?” A good team names both and explains why.
• “Which features would you fake by hand first?” A team that wants to automate everything is spending effort in the wrong place.
• “How are login, payments and backups handled?” Listen for named, proven providers and a restore test, not “we will add security later”.
• “What will we measure, and where will we see it?” If the core action is not tracked from day one, the MVP cannot answer its question.
• “Who owns the code and the accounts?” You should own the repository, cloud accounts and domain from the first commit.
At Geminate Solutions, clients own 100% of the code and IP, and we sign an NDA before we talk. That is how we approach MVP work across 50+ products shipped: narrow in features, solid in foundations.
If budget is on your mind, the biggest cost drivers in an MVP are the number of user roles, the number of integrations and how much of the core action is truly custom. Faking and skipping shrink the first two. Our guide to app development cost explains the other drivers.
Get your MVP plan sorted before you build
The quickest way to test your plan is to have someone sort it with you. Send us your feature list, your plan or the app you have already started. Within 24 hours you get a reply with your features sorted into build properly, fake by hand and skip, the riskiest assumption we think your MVP should test, and any gaps we spot in data, login or payments.
A rough list in a document is enough. You keep the sorted list whether or not we work together. If you go ahead, our custom development team can build the solid parts and help you plan when to automate the rest.
