What an MVP should include, in short
An MVP (minimum viable product) should include one job done properly for one kind of customer. It also needs the foundations that are expensive to add later. Those are accounts that belong to a company, roles checked on the server, billing states, a small admin and data protection. Leave out every other feature, and do by hand whatever you can until customers show they need it built.
This guide is for founders and managing directors at UK and EU companies commissioning the first version of a SaaS product from a development partner. You have a feature list, a budget and a date, and every guide you read tells you to cut. They're right about features. Many also tell you to skip user roles and the admin panel, and those are two of the things we'd keep.
Our SaaS product development page puts the reason in one line: the difference between a demo and a product is everything that happens off the happy path. This guide is about drawing that line before the build starts.
A prototype gets thrown away and an MVP doesn't
A prototype exists to test an idea, and you throw it away. An MVP is the first version real customers use with real data. It has to behave like a product from day one, even if it does only one thing.
Eric Ries made the term popular. In a 2009 post he defined the MVP as the version of a new product that lets a team collect the most validated learning about customers with the least effort. In the same post he warned that the MVP, "despite the name, is not about creating minimal products."
The UK government's Service Manual draws the same line. Alpha work should be just complex enough to test ideas, not production quality code, and teams expect to throw the code away. Beta is where they start building the best idea for real, first with a small group of invited users.
| Prototype or demo | MVP | |
|---|---|---|
| Who uses it | You, investors, people in a test session | Customers, on their own, with nobody watching |
| Data | Made up | Real, and usually personal |
| How long it lives | Weeks, then it's thrown away | Years, with version two built on top |
| What it must survive | A presentation | Wrong passwords, failed cards, a second user, a customer leaving |
| Data protection law | Only if real people's data goes in | Applies from the first real record |
The expensive mistake is the prototype that becomes the MVP by accident: it looked finished, customers were waiting, so it shipped. Generating something that looks finished has never been easier, and that is exactly the problem.
Cut features, not foundations
Judge every item on your list with two questions: does the first customer need it to do the one job, and what would adding it later cost? Features are cheap to add later. Foundations are not, because everything else sits on top of them.
Cutting features is the easy half. Pendo, which measures how people use software, studied 615 of its customers' subscriptions for a 2019 report. It found that 80 percent of features in the average software product are rarely or never used. A feature you leave out now can be built later with evidence instead of a guess.
Foundations are the hard half. Slack launched in 2013 on a simple model in which each user belonged to a single workspace. Its largest customers later needed one view across many workspaces, and the change potentially touched every API and permission check the Slack client used.
Scores of engineers worked on it, and the rollout finished in March 2024, almost two years after the first prototype. The simple model was a fair call in 2013. The lesson is what it cost to change.
Your two answers put each item in one of four groups:
| Cheap to add later | Expensive to add later | |
|---|---|---|
| Needed for the one job | Build a simple version now | Build it properly now |
| Not needed yet | Leave it out, or do it by hand | Design the slot now, build the screens later |
Most MVP checklists miss the bottom-right box. Your first version may have one role, one plan and one user per customer. The data model can still know that customers are companies with several users, that roles exist and that subscriptions fall overdue. On day one that's a few columns; in a live product it's a migration across every record you hold.
Accounts: decide who an account belongs to
Decide on day one whether an account belongs to a person or to a company. For most B2B products it's a company with several people in it, even if every early customer has only one user.
What the first version needs:
- Sign-up, sign-in and password reset, from a proven service such as Auth0 or Clerk rather than written from scratch.
- Every record tagged with the company it belongs to, and every query filtered by that tag.
- Invitations, so a colleague can join the company account without sharing a password.
- A way to close an account and to export or delete its data.
What can wait: single sign-on, teams inside a company, custom domains and profile settings beyond a name and an email address.
The company tag on every record is the part you can't add cheaply later, as Slack's two years show. It's also what keeps one customer's data off another customer's screen.
Roles: two are enough, checked on the server
Most MVPs need two roles: an owner who manages the account and a member who does the work. The permission check has to run on the server for every request. Hiding a button in the interface stops nobody.
Broken access control is first in the OWASP Top 10 for 2025, a list of the most critical security risks to web applications. Our guide to web apps vs websites explains why that risk arrives with the first login screen.
AI app builders make this easier to get wrong, because the screens look finished whether or not the rules underneath exist. A 2025 vulnerability record against Lovable, an AI app builder, says an insufficient row-level security policy let unauthenticated attackers read or write the database tables of generated sites. Lovable disputes it, on the grounds that each customer is responsible for protecting their own application's data. Whoever builds your MVP, that responsibility is yours.
When you design roles, keep two questions apart: what a person may change, and what they may see. A member might log their work without seeing the account's invoices. Store roles as data rather than scattering them through the code. A third role is then a new entry and some tests, not a rewrite.
Billing: invoice by hand if you like, but store the states
You don't need automated subscription billing on day one. You do need the product to know whether each customer is trialling, paying, overdue or cancelled, and what each of those states allows.
For the first handful of customers, an invoice and a bank transfer is a perfectly good billing system. Paul Graham's essay Do things that don't scale tells how Stripe delivered "instant" merchant accounts to its first users. The founders signed each one up for a traditional merchant account by hand, behind the scenes.
When you do automate, the states arrive with it. Stripe's documentation lists eight statuses a subscription can have, from trialing and active to past_due, unpaid and paused. Each needs a decision: does an overdue customer keep access, for how long, and who is told?
So even while you invoice by hand, store a status on each customer account and let the product check it. Changing who sets the status later is a small job. Adding the idea of a status to a product that assumed everyone pays is not. Our guide to SaaS billing beyond the happy path covers failed cards, downgrades and refunds.
Admin: the screens your team needs on day one
Build a small admin into the first release. Your team should be able to find a customer, see their account and its history, and change their plan or status. They should also be able to export a customer's data and close their account.
Several MVP guides suggest skipping the admin and managing early users straight in the database. For a UK or EU company holding personal data, that plan meets the law early. Article 25 of the UK GDPR and the EU GDPR says you must build data protection in from the design stage, in proportion to the risk. When a customer asks for a copy of their data, you have one month to respond.
A developer running queries on the live database can do both. But every fix then waits for that one person, nothing records who changed what, and one mistyped query can change every customer at once. An admin that logs each change solves all three.
Keep it plain: screens shaped around the questions your support person asks, in their words, rather than one screen per database table. The test is whether your team can fix the common problems without calling a developer.
What to leave out, and what to do by hand instead
Leave out everything that isn't the one job or a foundation. Most of it has a manual stand-in that works for the first customers and shows you what the built version should do.
| Leave out for now | Manual stand-in for the first customers |
|---|---|
| A self-serve onboarding wizard | Set up each new customer on a call |
| Integrations with other tools | CSV import and export, run by your team |
| Several pricing plans | One plan, with exceptions agreed in writing |
| Analytics dashboards for customers | A monthly report your team pulls from the admin |
| Notification settings | A few fixed emails: invitation, password reset, payment problem |
| Native mobile apps | A web app that works well on a phone |
| Single sign-on | Email sign-in with two-factor authentication |
| A public API | Exports on request |
| AI features outside the one job | Nothing, until customers ask for them |
Two exceptions. If you sell to larger companies, single sign-on can be a condition of the sale, so ask your first prospects before you cut it. And if your first market speaks another language, translation is part of the one job.
Manual work only holds while the numbers are small. Write down each manual step when you start it, with the point at which you'd build it: a number of customers, or hours a week.
Write the scope down before anyone builds
A written MVP scope should fit on a few pages and name six things:
- The one job, in a sentence a customer would recognise.
- The users: the kinds of company, the roles inside them, and what each role may see and change.
- The states: account (invited, active, closed), subscription (trialling, paying, overdue, cancelled), and whatever states your core job adds. A booking platform, for example, adds a payment schedule with states of its own.
- What's out: every feature you've cut, listed, so nobody builds one by accident.
- What's done by hand: each manual step, who does it, and when you'd build it.
- What "done" means: working in a shared staging environment, including the unhappy paths. Test a wrong password, a failed payment, a removed user trying to sign in and a brand-new empty account.
We work from written scopes, with weekly written updates and a shared staging environment. If you can't write the scope yet because the one job isn't clear, a discovery phase comes first. Our guide to the software discovery phase explains what it should produce.
When you don't need an MVP
You don't need to build software to test demand, and you don't need a custom product when an existing one does the job. Skip the build in any of these cases:
- You haven't tested the idea on buyers yet. A landing page, a clickable prototype or a service you run by hand will teach you more, sooner.
- An existing product fits. Our guide to custom software vs off-the-shelf sets out when building pays off.
- You need a website, not an application. If customers only need to find you, read about you and get in touch, see our guide to web apps vs websites.
- You need a demo for investors. Build a prototype, call it one, and plan to throw it away.
Software only your own team will use is different again. An internal tool still needs roles and a record of changes, but not sign-up, plans or billing.
Start with the list you already have
Take your current feature list and put each item through the two questions. Mark each one build now, design now, by hand, or later. If nothing lands in "design now", look again at accounts, roles, billing states and the admin. Send the marked-up list with your brief, and any studio, us included, can quote the product you mean rather than the demo.
Questions
Can we build the MVP with no-code or an AI app builder?
For a prototype, often yes, and it's a quick way to test an idea. Before real customers use it, check four things. Where does the data live, and in whose account? Do the access rules run on the server? Can you export everything? And who is responsible if data leaks? The Lovable record above answers the last one: you are.
Will we have to rebuild the MVP later?
Parts of it. Screens and features get reworked as you learn, and that is the point of an MVP. The foundations shouldn't need rebuilding: the account model, roles, billing states and the data itself. If the first version was really a prototype, plan to replace it. The GOV.UK Service Manual expects exactly that of alpha code.
Does the MVP need to be built to scale?
Not to millions of users. It needs to serve your first customers without errors, with monitoring and error tracking from the first deploy, so you hear about problems before a customer tells you. Performance work is a feature you can add with evidence. The account model is a foundation you can't.
Who should own the MVP's code and accounts?
You should, from the first day. When we build, the domain, hosting, repository and documentation sit in your accounts, and we transfer everything at handover. Put your payment provider account in your company's name too, because it holds the money and the customers' payment records. Ask anyone who builds for you for the same, in writing.
How we wrote this: drafted with AI, then checked and edited by the people who build our projects. Figures come from our own work or from the linked sources.