What it takes to build a SaaS MVP: scope, phases and the parts founders forget

Founders working out the cost to build a SaaS MVP usually picture the core feature: the dashboard, the matching engine, the scheduling grid. That part is often less than half the work. The rest is the plumbing every subscription product needs before a stranger can sign up, pay and trust you with their data.

This post walks through the phases of SaaS MVP development, then the parts founders most often forget, with what each one involves. We build multi-tenant products of our own, including Live Chat and Stay, so the examples come from that work.

We won't quote a price here. The cost to build a SaaS product depends on your scope, and the forgotten parts below are exactly why two quotes for "the same app" can differ so much. For how a quote gets built, see what moves the cost of custom software.

The phases of a SaaS MVP

Most first versions go through five phases.

1. Decide the one job

An MVP should do one job well enough that someone pays for it. Write it as a sentence: "A dog groomer can take bookings and deposits from their own website." Everything that doesn't serve that sentence waits.

2. Design the key flows

Sign-up, the core job, and getting paid. Clickable designs of those flows, tested with five real prospects, catch more problems than any specification.

3. Build in slices

Working software on a preview link every week or two. The first slice is often sign-in plus the core screen with fake data, so you can show it to prospects early.

4. Private beta

A handful of real customers, free or discounted, using it for real work. Expect to change things.

5. Launch and look after

Billing switched on, support in place, monitoring watching. The work doesn't stop here; it changes shape.

The parts founders forget

These are the pieces most often missing from early estimates.

Accounts, teams and roles

Most business software is used by teams, not individuals. That means invitations, an owner who can remove people, and roles such as admin and member. It also means deciding what happens when the only admin leaves the company.

Tenant isolation

In a multi-tenant product, every customer's data sits in the same system. One customer must never see another's records, even through a bug. This is the most important architecture decision in a SaaS product, and it has to be designed in from the first table.

In Live Chat, every search filters by site before anything else, so a passage from one business's knowledge can't come back in another business's answers. The widget also checks, every time it starts, that it is running on a domain the business listed. We test isolation against a real database, not mocks, because that is where the bug would live.

Billing and dunning

Taking a first payment is easy with Stripe. The work is everything after: trials, upgrades and downgrades mid-month, failed cards, retries, reminder emails, and what the product does when a payment finally fails. That follow-up on failed payments is called dunning. Get it wrong and you either lose revenue or lock out paying customers by mistake.

An admin console for you

You will need to look up a customer, see their plan, reset something on their behalf and read what went wrong. Without an internal console, every support request becomes a database query run by an engineer.

Email that actually arrives

Sign-up confirmations, password resets and receipts must land in the inbox, not spam. That means a sending service, a properly set up domain with SPF, DKIM and DMARC records, and templates that work in every mail app.

Backups and a restore you have tried

Automatic database backups are standard on managed hosting. A tested restore is not. Do one before launch, and write down how long it took.

Audit logs

Who changed what, and when. Customers in regulated industries will ask, and you will need it yourself the first time a customer says "we didn't change that."

A staging environment

A copy of the product where changes are tried before they reach customers. Without one, every release is a test on live users.

Monitoring and alerts

You should hear about errors and downtime before your customers email you.

Legal pages and data handling

Terms of service, a privacy policy, and a plan for deleting a customer's data when they leave. A lawyer should review the documents; the software has to do what they promise.

A decision that pays off: let the database enforce the rules

One pattern we lean on in our products is putting critical rules in the database, not only in application code. In Stay, our booking software for inns, a hold, a reservation and a blocked date all claim nights in the same table. A database constraint refuses any overlap. Even if two guests press "book" on the last room at the same instant, or a bug slips through, the database won't allow a double booking.

Rules enforced in one place are rules you only have to get right once.

Ways to keep the first version small

• Sell to one kind of customer first.
• Use Stripe's hosted pages for checkout and billing management instead of building your own.
• Run onboarding by hand for the first twenty customers.
• Skip a mobile app until customers ask for one; a responsive web app goes a long way.
• Write the admin console as plain tables and forms. It doesn't need to be pretty.

Questions to ask a developer

1. How will you keep one customer's data away from another's, and how will you test it?
2. What happens when a card fails?
3. Will I own the code, the hosting account and the Stripe account?
4. Can I see working software every week or two?
5. What does running it cost each month at 10 customers, and at 500?

Our web applications page covers how we build products like these.

Talk about your product

Send the one-sentence job your product does and who pays for it. We reply within one business day, and the written scope will say plainly what the first version leaves out. Start here.

Cover photo by Annie Spratt on Unsplash.