What Should Be in an MVP (And What Will Waste Your Budget)

Founders ask what should be in an MVP as if there were a universal feature checklist. There is not. An MVP (minimum viable product) is the smallest product that lets a real user put a business test under load. There is a test. If a line item does not change the test, it does not ship — even if it is “table stakes,” even if a competitor has it, even if a designer already drew it.

A common failure is spending the budget on login, payments, admin, and polish while the core promise is still a guess. The software looks like a company. The company has not learned anything. That is not lean. That is an expensive demo.

This article is a cut method you can run this week: three columns, the usual traps, and a rule you can enforce in a meeting without a 40-page spec. For the document shape, see MVP blueprint vs PRD. For money, see MVP development cost.

What should be in an MVP: three columns, not a backlog

Open a page. Three headings: Must ship. Not in v1. Validate first.

Must ship is the smallest path that makes the promise true for one user type. If you sell “we replace this weekly spreadsheet,” the path is: get the data in, do the job, get the result out. Anything that does not sit on that path is a candidate for the other columns.

Not in v1 is not “never.” It is “not until the test passes.” Referral programs, a second platform, a public API, a theme switcher, a custom CMS for marketing pages — they have a home. Their home is not the first invoice to a developer.

Validate first is work that should not be software yet. Interviews, a landing page, a concierge run, a paid pilot. If you put “AI recommendations” in must-ship before anyone has paid for the dumb version, you are validating a slide. Read how to validate a SaaS idea (software as a service — software you sell on a subscription).

Do this in 90 minutes with a co-founder, not in a month of Figma. If you cannot fill the columns, you do not have a disagreement about UI. You have a disagreement about the business.

If it does not change the test, it does not ship

Write the test as a sentence with a number: “Five companies will complete the weekly workflow and pay for two months.” Then walk the backlog. Each feature either makes that sentence possible, makes it faster, or does nothing.

Faster is optional in version one. Possible is not. Dark mode does not make the sentence possible. A second user role might — if the buyer is a team. It might not — if you can start with one operator and a shared login you will replace later. A slightly embarrassing shortcut now is often the correct engineering trade.

“We’ll need it eventually” is how budgets die. Eventually is a real place. It is not a reason to pay for it before you have evidence. Competitors already have eventually. You do not have their revenue.

If two founders disagree, they are usually arguing without a test. Put the sentence on the whiteboard. The feature that cannot point at the sentence loses. If neither of you can write the sentence, stop building. You are assembling a product for a user who does not exist yet.

User-requested features are not automatically must-ship. Users are generous with other people’s roadmaps. Ask what they do today and what they would pay to stop doing. Then see whether your version one has to include their seventh request.

Login: only if the test needs a returning user

Authentication is not free. Magic links, password reset, email deliverability, social login, invited users, single sign-on — each is a project. Include login when the test requires a returning individual or a permission boundary you cannot fake.

You can often start with a unique URL, a basic login, or even a manual account you create for the first five design partners. That is ugly. Ugly that learns is better than a polished gate in front of an empty product.

Single sign-on and SCIM belong when a buyer with a security questionnaire is the test. If your first users are three operators who already share a spreadsheet password, do not build enterprise identity to feel ready for a Fortune 500 that has not spoken to you.

Roles: every extra role is extra interface, extra bugs, extra support. One role until the test says you need two.

Payments: a real charge versus a fake button

If the test is willingness to pay, a real invoice or a real checkout is in must-ship — or it sits in validate-first as a concierge charge you run by hand. A fake “upgrade” button that never bills does not test payment. It tests whether people click a painted button.

If the test is usage of the workflow, you can collect payment later. Do not build plans, coupons, usage meters, tax, and dunning because a SaaS blog said you must. One price, one path, one currency you actually operate in.

Marketplaces, splits, and escrow are a different company. If your version one needs them, you may not have an MVP. You may have a two-sided business you have not validated on either side. Validate one side first.

Refunds and failed cards will happen. Handle them in operations at first if volume is tiny. Automating a department you do not have is how MVPs stall.

Admin: a second product pretending to be a feature

You will need a way to help the first users: reset something, inspect an account, fix a bad import. That can be a database tool, a script, or a tiny internal page. It does not need to be a staff product with analytics, impersonation, audit logs, and a design system.

Admin for imaginary scale — “when we have 10,000 tenants” — is a gift to a bored engineer. You do not have 10,000 tenants. You have a test.

If you are the support desk, write down the five actions you will actually perform in week one. Build only those. Everything else is not in v1.

Customer-facing “admin” for their own team is a role problem. If the buyer is a single operator, skip team admin. If the buyer is a department, you may need invite and a permission. Still not a full IAM suite.

Polish that does not belong in version one

Polish is not quality. Quality is the core path working. Polish is empty states, illustrations, micro-copy, marketing animations, and a unique visual identity. Buyers in a paid pilot will forgive a plain interface that does the job. They will not forgive a beautiful interface that does not.

Two mobile operating systems is a polish-and-platform trap. If the test can run on the web, run on the web. Native is a product, not a checkbox.

A custom CMS for the marketing site is a trap. Use an ordinary CMS or a static page. Your product is the product.

Analytics for a product with no users is a trap. One event on the core action is enough. A data warehouse is not.

AI because the deck needed a slide is a trap. If a rules engine or a human-in-the-loop does the job for the first five customers, do that. You can say so without apology.

Onboarding tours, elaborate sample data, and referral widgets are how teams avoid the core path. If a user cannot complete the job with a one-page instruction you paste into email, the product is not ready for a tour. The path is wrong.

Accessibility of the core path is not polish. A user who cannot complete the job because the contrast is unreadable, or because the only flow is a drag-and-drop that fails on their laptop, has not taken your test. Fix the path. Do not add a fourth illustration.

A cut you can finish this week

1. Write the test in one numbered sentence.
2. List every feature anyone has asked for. Be exhaustive once.
3. Sort into must / not in v1 / validate first. No fourth column called “maybe.”
4. For each must-ship item, write how it changes the test. If you cannot, move it.
5. Circle login, payments, admin, polish. Justify each with the test or cut them.
6. Give the must-ship list to a builder and ask what it costs. If the number is impossible, you did not cut. Cut again.
7. Schedule the validate-first items as actual conversations or invoices this week — not as tickets in a tracker.

If the meeting turns into taste (“I just like it”), you have left the method. Return to the sentence.

Run that meeting with a timer. Forty-five minutes for the sort. Fifteen minutes to justify login, payments, admin, and polish. If an item is still in “maybe,” it is not in version one. Ambiguity is how the expensive list returns after the meeting, in a side chat with the developer.

Send the three columns to anyone who will quote the work. If they add items “everyone expects,” ask which column those items belong in. If they cannot say, they are selling a template, not your test. Templates are how you buy a CMS, a notification center, and a dashboard you will not look at.

I will not build the MVP in a consulting package. I will help you cut it. Idea Validation is $149 for 45 minutes if you should not be in a build meeting yet: a diagnosis and a next test, no written report. Product Strategy is $299 for 60 minutes plus an action summary if the fight is priorities. MVP Blueprint is $599 (featured): 90 minutes and a 4–6 page scope — not unlimited revisions and not development. Founder Advisory is $999/month, up to 20 hours, unused expire, independent contractor, not employment. Private Founder Advisory from $1,500/month is a separate inquire path. Implementation is not included.

Book through the consultation page. Fees are non-refundable once paid, except if I cancel and we cannot agree a new date.

Ship the test. Leave the rest on the page labeled later. Later is a privilege you earn when the test passes.

Questions people ask