You have a SaaS idea and you're trying to work out what to build first. Do one thing today: finish this sentence on paper. "My product helps [specific person] do [specific thing] so they can [specific outcome]." If you can't fill it in, more code won't help yet.
This guide is the process I use as an AI-augmented full-stack engineer, drawn from projects like Callidus and BookBed. If you want a definition first, read what a SaaS MVP is, then come back. For the long-form version of this topic, see the SaaS MVP development guide.
How do you define and scope a SaaS MVP?
Define the problem in one sentence, talk to potential customers before writing code, then cut everything except the one workflow that lets a specific customer solve a specific problem and pay you for it.
Write the problem sentence
Consider a hypothetical example: "My product helps independent physiotherapy clinics manage appointments so they stop losing bookings to missed calls." That sentence tells you what to build. Compare it with "My product helps businesses manage operations more efficiently," which could mean anything and therefore gives you nothing to cut. A vague sentence is the early sign of an MVP that grows for months without a clear finish line.
Validate the problem before the product
CB Insights' 2026 analysis of 431 VC-backed companies that shut down since 2023 found poor product-market fit as a cause in 43% of the 385 it could categorize. Running out of capital topped the list at 70%, but CB Insights notes that's the final cause, not the root problem. My inference is that a cheap way to lower your risk is to test demand before you spend your runway.
Talk to potential customers, not through surveys but in actual conversations. Ask what they use today, what breaks about it and what that problem costs them each month. If nobody can put a cost on the problem, it may not be painful enough to pay for. A good sign is when people describe the workaround they built themselves, such as a spreadsheet, a shared inbox or a paper calendar, because they're already paying for the problem with their time. Aim for enough conversations that you hear the same pain repeated, and write down the exact words people use, since those words become your landing page copy later.
Cut the scope, not the quality
An MVP is not a small version 1. It's the smallest set of features a paying customer would actually use. For most B2B products that means:
- The core workflow that solves the stated problem
- Email and password authentication
- Data isolation between accounts, if more than one customer will share the product
- A working payment flow
- One notification channel, usually email
Admin dashboards, native mobile apps, multi-language support, advanced analytics and social login can usually wait. You can manage early data from your database console, and each cut item comes back once paying customers ask for it. The feature prioritization framework shows a way to rank what's left, and the MVP cost breakdown explains what drives budget.
Which tech stack should a SaaS MVP use?
Pick the stack your developer knows deeply; for a web SaaS with relational data, React or Next.js with Supabase and Stripe is a sensible default, and Flutter with Firebase suits mobile-first products.
That's a recommendation, not a rule. I build on React/Next.js with Supabase, or Flutter with Firebase, depending on the requirements. The Supabase vs Firebase comparison covers the trade-off. Short version: relational B2B data favors Supabase, while a mobile-first product with heavy real-time needs can fit Firebase. Callidus, for example, runs on React, Firebase and Stripe Connect, so the stack follows the product.
Check the free-tier limits before you rely on them
Plans and limits change, so I checked the vendors' pricing pages on 30 September 2026:
| Service | What's included on the entry plan | Watch out for |
|---|---|---|
| Supabase | Free: 500 MB database, 50,000 monthly active users, 1 GB file storage. Pro from $25/month | Free projects are paused after 1 week of inactivity, and you can keep up to 2 active free projects |
| Resend | Free: 3,000 emails per month, 100 per day, 3 domains. Pro from $20/month for 50,000 emails | The daily cap matters for a busy launch day |
| Vercel | Hobby is free | Hobby is restricted to non-commercial, personal use, so a product with paying customers needs a paid plan or a different host. Pro developer seats cost $20 per user per month |
The Vercel row changes an old assumption. Many guides, including an earlier version of this one, said free tiers cover MVP costs. Once customers pay you, the commercial-use rule means that's no longer true for Vercel's free plan.
Authentication
Use your platform's authentication instead of writing your own. Supabase ships with auth, and Next.js projects can use an established library. Session handling, password reset and token storage are easy to get subtly wrong, and a mistake there exposes every customer. Email and password is enough for an MVP. Add social login later if your users ask for it.
Payments
I use Stripe for subscriptions. Stripe's subscription guide offers a Stripe-hosted Checkout page, an embedded Checkout page and Elements-based integrations, so the quickest route is usually the hosted page, and you can move to something more custom later.
Tenant isolation
If several customers share one database, isolation has to exist from the first table. Supabase's row level security documentation says a table in an exposed schema without RLS is readable and writable by any role with a grant on it. Adding isolation to a finished schema is painful, so plan it early. The multi-tenant architecture guide explains the options.
In what order should you build a SaaS MVP?
Build authentication first, then the core data model, core workflow, billing and email, and leave polish for last, wiring up billing before your first customer demo so nobody ready to pay is turned away.
- Authentication. Login, signup, password reset, sessions. Use your platform's auth instead of building your own.
- Core data model. The tables and relationships your product is built on.
- Core workflow. The one thing your MVP must do.
- Billing. Subscription setup before you talk to any customer who wants to buy.
- Email notifications. The minimum that makes the product usable.
- Basic polish. Enough not to look broken.
How long it takes
My published range for a production SaaS MVP is 6 to 12 weeks, depending on scope, and the price is agreed per project. Callidus was built solo in roughly ten weeks, per its case study. As a planning template, not a promise, you can split that time like this: foundations and data model first, the core workflow next, then billing and email, a staging environment, a small beta and a feedback round. The MVP timeline entry explains what moves the dates.
Who should build it
| Option | Fits when | Main trade-off |
|---|---|---|
| Build it yourself | You're technical, have time and want full control | The learning curve is steep and your own time is the cost |
| Freelancer | You have a clear spec and can manage the project | You carry the coordination; scope is usually narrower |
| Agency | You need design, development and QA under one contract | More layers and approvals |
The agency vs freelancer comparison goes deeper. If you'd like an engineer who works directly with you, I work with SaaS startups from scoping through launch.
How do you get your first paying customers?
Start selling before the product feels finished: find people in the communities where your customer already spends time, offer beta access for feedback, and put a real price on the product early.
Talk first, then price
Reach out personally on LinkedIn, in Slack groups, in forums or on Reddit. Your goal is learning, and the conversations will reshape the product faster than solo iteration. Set a price before launch, because "free while in beta" trains users to expect free forever. Keep pricing flat with one or two tiers. Callidus, for example, sells monthly plans at £15 and £50 with a 14-day free trial, per its case study. That price suits that market, not yours.
What counts as launched
For me, launched means the product lives on a real domain, billing works, at least a few customers pay and you're collecting feedback. After that the job changes from building to listening.
Track trial-to-paid conversion, monthly churn and time to first value from day one. I don't give target percentages, because good numbers depend on your price, market and sales motion. Watch the trend and where new users stop.
Talk to the people who don't convert
The most useful conversation is often with a trial user who left. Ask what they expected to happen, where they got stuck and what they used instead. Three honest answers usually point to one fixable problem, such as an onboarding step that assumes too much or a missing import, and fixing it often beats adding a new feature. Keep a simple log of these answers in a document you review each week, so patterns show up before you commit engineering time to a guess.
What kills MVPs most often
Over-scoping, building without customer conversations and waiting for perfect are the patterns I see most. Unit economics matter too: know what a customer costs you to acquire and what they're worth before you raise money.
Which single feature on your list could you cut today without losing the workflow that customers would pay for? Write it down, then send me your scope and I'll tell you what I'd cut next.