SaaS & Products
SaaS MVP Development: What Belongs in Version One?
An MVP is the smallest end-to-end product that proves the important assumption. Here is how to find that boundary before you spend the build budget.
Richard Higgins · Co-founder, Emerald Sites · 22 August 2026
What an MVP is not
An MVP is not a pile of half-finished features, and it is not a demo that falls over the moment a real user touches it. It is the smallest end-to-end product that proves the assumption your business depends on, delivered at a quality level a real user can trust for the one journey that matters.
That definition has two edges. Smallest: everything that does not serve the proof is cut without mercy. Credible: what remains actually works, handles its edge cases and does not embarrass you in front of the first ten users.
Start with the moment, not the feature list
Every good v1 is built around a single moment: the journey where a user does the thing that makes the product valuable. For a prompt tool it is getting a visibly better prompt out of a rough request. For a booking product it is completing a booking. For an internal tool it is the task that used to take an afternoon taking ten minutes.
Write that moment in one sentence. Everything in v1 exists to make that sentence true for a real person. Features that support it are candidates. Features that do not are v2, no matter how exciting they are.
The six questions that draw the boundary
In discovery we work through six questions, in order. They look simple. They are not, and the arguments they cause are exactly the arguments you want before money is spent on engineering.
- Problem — what is difficult, expensive or impossible today, stated in the user's words rather than yours?
- People — who experiences the problem, and who decides to adopt? A tool used by staff but bought by a founder has two audiences from day one.
- Moment — which single journey proves the product is useful?
- Boundary — what is deliberately not in v1? Say it out loud and write it down.
- Evidence — what behaviour would tell you to continue, change or stop? Decide before launch, or you will rationalise whatever happens.
- Release — what must be true for a credible first launch: performance, security basics, support route, rollback?
The usual suspects to leave out
Some features feel essential and almost never are for v1. Team roles and permissions, unless the moment itself requires two kinds of user. Notification systems beyond the one email that matters. Settings screens for things nobody has had time to want to change. Dashboards full of charts when three honest numbers would do. An admin panel, when the founder can answer the same question with a database query once a week.
Each of these is real work with real edge cases. Deferred, they cost nothing. Built early, they eat the budget that should have gone into making the core journey excellent.
What must not be cut
Credibility has a floor. Authentication and account recovery that actually work. Sensible handling of user data, with plain answers about where it goes. Error states that explain rather than expose. A way to contact a human. Basic performance and accessibility. These are not polish; they are the difference between a product people forgive and one they abandon silently.
This is where a disciplined delivery process earns its keep: acceptance criteria agreed before the build, testing treated as delivery work rather than a launch-day afterthought, and a release that includes a way back.
What this means for budget and timing
A scoped MVP is priced after discovery because the honest number depends on users, data, integrations and assurance needs. Early certainty that ignores those things is not useful certainty—it is a guess wearing a suit.
The good news is that discovery itself is small and finite. A week or two of structured thinking produces journeys, a prioritised scope, architecture options, risks and a release plan: everything a credible proposal needs. Whether you build with us or someone else, that document is the difference between buying a product and buying a surprise.