SaaS product MVP
Sign-in, an account and one scenario carried through to the end. That is enough to put the product in front of the first customers and see whether they come back.
Maciej Nuzia · MVP
A web app MVP is the first version ready for users
An MVP should handle one important path from beginning to end. We write down the other features for later. Once the first version reaches users, you can see what is genuinely missing and which ideas can wait.
The tool works from what you type into it. The narrower the scope you describe, the closer it lands to a real MVP.
The risk
A long scope delays the first test with users
The scope of a full product is made of assumptions nobody has checked yet. Every one of them gets written anyway, and the test comes at launch, which is as late as it gets.
- a wider scope pushes back the moment there is anything to show
- the bill grows before a single outsider opens the app
- features nobody ends up asking for cost exactly as much as the rest
- the order of work comes from opinions round a table, because there is no data yet
Who it's for
Start with one audience and one task
If you know who the product is meant to help, and you can describe one situation where it earns its place, there is something to cut an MVP out of. When nobody can describe that situation yet, conversations with the people it is for will cost you less, and so will discovery of the process before anybody writes a line of code.
- Founders without a technical team
- Companies testing a product alongside the main business
- Product teams facing a bigger investment
- Companies that need something to show investors
- Teams running a process out of a spreadsheet
- Service businesses with an idea for a tool of their own
Examples
What a first version can look like
One spreadsheet fewer
An app that takes over what a spreadsheet does today. The answer arrives fastest here, because the users sit one floor down and say plainly what gets in their way.
One path, start to finish
The whole product comes down to that single path, from the way in to the result. It has to be done properly, and the other screens can wait.
Prototype with an AI feature
A check on whether the model really does shorten a specific task before you build a product around it. That question can be settled on one task and one screen.
A panel the customer runs alone
The basic data and a few actions available at any hour, including the ones when nobody is in the office.
Integration with one system
A version whose entire value sits in the link to one outside system and in what its data makes possible.
Order of work
I cut the scope before any code is written
Cutting the scope is part of building the first version. Walking the process at your place, with conversations and a map at the end of them, is separate work, and I describe it on the page about discovery and the requirements document.
01
Why this version exists
One sentence that is going to turn out either true or false. Until it is written down, every feature looks necessary and the list grows on its own.
02
The feature list goes into two piles
I sort them into the ones without which that single path does not close, and everything else. The second pile goes on a list to come back to once the first users have had their say.
03
That one path, carried to the end
I build it so it can be used in production, because that is where you find out at which point people get lost.
04
The first users, and the call that follows
The version lands with the first users. What you learn from them decides what to add and what to drop.
Technologies
Technologies I use to build and develop the product
I reach for tools I know well enough that you are not paying for my learning curve.
- React
- Next.js
- TypeScript
- Node.js
- PostgreSQL
- OpenAI API
- Docker
- AWS
- REST / API
Where it goes wrong
Common mistakes when building an MVP
An MVP that grew into the full product
With every new feature I go back to that one sentence from the start and ask whether the answer changes without it. If it does not, the feature waits, however good it is.
A success measure agreed after the fact
When nobody settles upfront what counts as working, everyone reads the same numbers their own way once it ships. Better to agree on it while there is still nothing to argue about.
Shortcuts that stay for years
Fast does not mean sloppy. I take shortcuts deliberately and write down where they lie, so they can be undone later.
FAQ
Questions about a product’s first version
What exactly is an MVP?
The simplest version of a product: one path from beginning to end and nothing beside it. Once it is out, you know whether the idea meets a real problem, because somebody has already tried to solve it that way. I narrow the scope, and whatever gets inside it has to run in production and survive contact with a person who clicks in their own way.
What decides how long an MVP takes?
The number of screens in that one path, how much data has to come in from outside, and how fast decisions are made on your side. I give you a date once I know those three things.
What happens after the MVP?
You know how people use it and where it stops working for them. That sets the order of what comes next. I write the first version so it can be grown further, because a rewrite from scratch can be the most expensive way out.
What if it turns out the idea did not land?
That is a result too, and much better to have it now. There is a middle case as well: it works, and the people it works for turn out to be a different group. Then the audience changes and the code stays.
How much does an MVP cost?
I give you a price once the scope is settled, because only then is it clear what the price covers. What pushes that price up hardest is the number of integrations and how many exceptions have to be handled.
Scope on paper
Describe one path the MVP should handle
Start with that single path and put it into the estimation tool. What comes back is a report that makes it easier to judge whether the scope can still be narrowed. Then there is something to talk about.