An MVP exists to find out whether anybody will pay for this.
Most first versions are too big. The feature list grew out of every conversation the founder had, and each addition felt small at the time. A year later there is a great deal of software and no customer.
A useful first version does one job, for one kind of buyer, well enough to charge for. The rest waits until somebody has paid and then asked for it.
A SaaS MVP is the smallest version of a subscription product that a real customer can work in and pay for. Not a prototype and not a demo. It has sign-up, the single workflow the product exists for, and a way to take money. Anything that does not serve that workflow is a decision for later.
Where it earns its place.
What has to be right from the first version
A few decisions get expensive once customers exist, so we make them properly even in a small build.
- Separation between customers’ data, settled before the second one signs up
- Sign-in, roles and who may see what
- A data model that matches how the work is really done, not how it is described
- Billing attached to something, even if the first invoices go out by hand
- Enough visibility to see what a customer actually does in it
What can wait, and usually should
- A settings screen for everything, while a database change will do
- More than two roles
- A mobile app, unless the work happens away from a desk
- Self-serve onboarding, while you can still set each customer up yourself
- Reports, until a customer has asked for the same one twice
- An admin panel beyond what your own team needs on a Monday morning
How a first version runs
- One workflow
- First customers
- Charge
- Watch
- Widen
- Agreeing the single job the product does, and writing it in one sentence
- The shortest path through that job, screen by screen
- A real deployment, real sign-in and real payments, not a sandbox
- A handful of customers doing their work in it while you watch
- The second version built from what they did, rather than what they asked for
Do the unscalable parts by hand
Software is the expensive way to test an idea, and several things do not need building yet.
- Onboarding each customer on a call instead of through a wizard
- Raising the first invoices yourself
- Answering support on WhatsApp rather than in a ticketing system
- Running the monthly report manually and emailing it
- Importing their data for them, which also shows you what their data is like
Each of these becomes a feature later, and by then you will know exactly what it should do.
A product, or one customer’s system?
This distinction decides the architecture, and getting it wrong costs money in both directions.
- One customer paying for it built their way: that is custom software
- Many customers sharing one system, each seeing only their data: that is SaaS
- A product every customer needs differently is a services business with software attached
- Multi-tenancy retrofitted onto a single-customer build is close to a rewrite
There is nothing wrong with custom software. It only causes trouble when it is sold as a product by accident.
When this is the right choice.
- A product idea with a first buyer you can name
- A workflow several businesses do the same way, badly, today
- A founder willing to cut the list down to what the first customer needs
- Money involved from the start, even at a pilot price
- A clear answer to who sells it, which decides more than the technology will
When it is not.
- An idea nobody has tried to sell yet, where conversations cost less than code
- A workflow every customer wants differently, which is custom work and should be priced as such
- A market with a mature tool where your only difference is being cheaper
- A build with nobody to sell it, because a finished product does not find its own customers
- Replacing a spreadsheet that works fine for the one team using it
Questions we are asked about it.
How small should the first version be?
Small enough to describe to a customer in one sentence they understand. If the sentence needs the word “and”, something in it can probably wait for the version after this one.
Can we add multi-tenancy later?
You can, and it is among the more painful pieces of work in this trade. Every query, permission check and export has to learn about the tenant. Building it in at the start is far cheaper, even with one customer.
Should we charge from the first customer?
Yes, even a small amount. A free pilot tells you people are polite. A paid invoice tells you the problem was real, and it surfaces the approvals and procurement that will slow every later sale.
Should the first version have AI in it?
Only if the AI is the product. Otherwise it distracts from the workflow you are trying to prove. Adding it later, once you can see what people do in the product, is usually straightforward.
Who owns the code?
You do, in your own repository from the first commit. We work inside it, review changes there, and leave the deployment steps written down. That holds whether you continue with us afterwards or not.
What happens after the MVP?
Usually a stretch of small changes driven by the first customers, then a decision about whether to widen. Some products earn a second phase. Some tell you plainly to stop, and that answer saves the most money.
Services that use it.
What it sits with.
Not sure SaaS MVP is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- We reply the same working day
- Your details stay private