Building a SaaS MVP: the essentials

A SaaS product is a set of rules about who can see what, wrapped around one useful job, with a bill at the end of the month. The MVP needs all three of those parts, but only the simplest version of each. Most of the time and money in a first SaaS build goes into features that are standard in mature products and unnecessary in a new one.

I was the first designer at a B2B SaaS company, and most of what I learned there about first versions is in this list. It is part of my guide to how to build an MVP.

The essentials, in detail

These are the parts I would not launch a SaaS MVP without. None of them are exciting. All of them are cheaper to build properly the first time than to fix after real customers arrive.

Sign-in that is boring and secure

Email and password or a magic link, plus one social provider if your users already live in it. Password reset that works. Sessions that persist across a refresh. Use a well supported auth provider or your database platform's built-in auth rather than writing your own. Teams, SSO and two-factor authentication can come later unless your buyers require them.

One core workflow, done properly

The one job your product does, end to end, including the unhappy paths. If it is a reporting tool, that is connecting data and seeing the report. If it is a booking tool, it is setting availability and taking a booking. This is where design time should go, because it is the part customers judge you on.

Data isolation between customers

In a SaaS product many customers share one database. Each must only ever see their own data. That rule belongs in the database, not only in the interface, because the interface is not the only way to reach your data.

If you build on Supabase, for example, its docs say to enable row level security on every table in an exposed schema, and that once it is enabled no data is reachable through the API with a publishable key until you add policies. Here is the docs' own example of a policy that lets signed-in users read only their own rows:

-- From the Supabase row level security guide. Adapt table and column names.
alter table todos enable row level security;
 
create policy "Individuals can view their own todos."
on todos for select
to authenticated
using ( (select auth.uid()) = user_id );

For a B2B product, the same idea usually keys on an organisation or account ID rather than the user. Missing or loose rules here are a common problem in AI-built apps, and they are invisible in a demo.

Subscription billing without building billing

Use Stripe. Payment Links create a hosted payment page without code, and they support subscriptions. Checkout gives you the same hosted page from your own code when you need more control. Then switch on Stripe's customer portal, which lets customers update billing details and payment methods, change or cancel subscriptions and download invoices, and can be set up in the Stripe Dashboard without code.

What you do need to build is the webhook handler that tells your app a customer has paid, changed plan or cancelled, so access matches what they pay for. That part is small but it has to be right.

One limit to plan around: Stripe's docs say that subscriptions using usage-based billing, multiple products or trials can be cancelled in the portal but not updated there. A flat monthly or annual plan keeps things simple.

A handful of transactional emails

Welcome, password reset, receipt, and the one event your users are waiting for. Use a transactional email service and set up your sending domain properly so the emails do not land in spam. A notification centre and preference settings can wait.

Error tracking, backups and logs

You need to know when something breaks before a customer tells you, and you need to be able to restore the database if something goes wrong. Neither is visible to users. Both are what make it safe to have users.

Legal pages that match reality

A privacy policy and terms that describe what the product actually does, and a cookie banner if you set cookies that are not strictly necessary. The ICO's guidance under PECR is that you need consent before setting non-essential cookies, and that cookies strictly necessary for a service the user asked for, such as remembering a shopping basket, are exempt. If your analytics set cookies, plan for consent.

The trade-offs in practice

A familiar argument at the start of a SaaS MVP: someone wants teams and roles, because a future customer will need them. The honest test is whether a single user can get value alone. If they can, one account per company, with you adding extra users by hand when asked, is enough for the first customers.

The same goes for integrations. Ask your first three customers which one tool they need connected. Build that one. Usually it is a CSV export, which takes an afternoon.

What is in and what can wait

What to cut from your MVP goes deeper on the right-hand column, with alternatives for each.

Pricing and trials

Pricing is part of the MVP, not something to bolt on after. The main question an MVP answers is whether people will pay, so they need to be able to.

Keep it to one or two plans. Decide whether you offer a trial, and if so, how long. My view is that a short trial with a card up front, or a money-back promise, teaches you more than a free plan, because it separates people who want the product from people who are curious. Whichever you choose, make sure your webhook handling covers the end of a trial, a failed renewal and a cancellation, because those are the moments access should change.

Where AI fits

Many SaaS MVPs now include an AI feature, such as summarising, drafting or classifying. If AI is the core job, the cost, rate limits and testing need their own plan, which I cover in building an AI tool MVP. If it is a side feature, consider leaving it for version two. It adds per-use costs and a new kind of failure to a product that does not yet know whether people want its main job.

Next step

Write your SaaS feature list, then sort it with the MVP scoping tool, or follow how to scope an MVP in one afternoon. Put the must-haves through the MVP cost calculator for a price and a timeline. For what similar builds cost across agencies, freelancers and AI tools, see what an MVP costs in the UK.

My MVP Build covers exactly this list: design, sign-in, the core workflow, Stripe payments and deployment on your domain, from £12,000 and usually 4 to 6 weeks.