Most SaaS products fail before launch — not because of bad code, but because of bad scoping. This guide covers everything I have learned building Bookbed and Callidus: how to define what to build, which stack to use, what to skip, and how to get from idea to paying customers in 90 days or less.
If you want a definition first, read what a SaaS MVP actually is — then come back. If you want to know what realistic timelines look like, check the MVP timeline guide.
Step 1: Define the Problem, Not the Product
Before writing a line of code, write one sentence that completes this: "My product helps [specific person] do [specific thing] so they can [specific outcome]."
If you cannot fill that in, you are not ready to build. Founders who skip this step build feature-complete products nobody uses.
Good example: "My product helps independent physiotherapy clinics manage patient appointments so they can stop losing bookings to missed calls."
Bad example: "My product helps businesses manage operations more efficiently."
The first one tells you exactly what to build. The second one could be anything — and that ambiguity will cost you 6 months and €30,000.
Validate Before You Build
Talk to 10 potential customers before writing code. Not surveys. Actual conversations. Ask:
- What do you currently use for this?
- What breaks about that?
- How much does that problem cost you per month?
If nobody can quantify the cost of the problem, the problem is not painful enough to pay for a solution.
Step 2: Scope Your MVP Ruthlessly
An MVP is not a version 1. It is the minimum set of features that lets one specific customer solve one specific problem and pay you for it.
The SaaS MVP cost guide breaks down realistic budget ranges by feature set. Most founders try to build 3 months of work in 3 weeks. The fix is subtraction, not speed.
What to Include
- The core workflow that solves the stated problem
- Authentication (email/password is enough for MVP)
- Basic billing integration (Stripe is the only choice)
- One notification channel (email)
What to Cut
- Admin dashboards (use your database directly at MVP stage)
- Mobile app (web-first, always)
- Multi-language support
- Advanced analytics
- Social login
- Notification preferences
Everything on the cut list can be added post-launch when you have paying customers telling you what they actually need.
Step 3: Choose the Right Tech Stack
Wrong stack choices at MVP stage cost you 3–6 months. Here is what works.
Frontend
Next.js is the default choice. App Router, server components, and built-in API routes mean you ship a full-stack product with one framework. TypeScript from day one — the type safety pays for itself by week two.
Backend / Database
For most B2B SaaS MVPs, Supabase is the right choice. You get Postgres, auth, storage, and edge functions in one platform. Faster to prototype than building your own backend, and production-ready when you scale.
The Supabase vs Firebase comparison breaks down which to choose based on your use case. Short version: if you need a relational data model (most B2B SaaS), Supabase wins. If you need real-time everything and are building consumer-facing, Firebase is viable.
Payments
Stripe. No alternatives worth discussing at MVP stage.
Resend for transactional email. Simple API, excellent deliverability, generous free tier.
Hosting
Vercel for frontend. Supabase handles backend hosting. Both have free tiers that cover MVP validation costs.
Step 4: Architecture Decisions That Matter
Get these right at MVP and you avoid expensive rewrites later.
Multi-Tenancy from Day One
If you are building B2B SaaS, every data table needs a tenant_id column from the start. Adding tenant isolation to an existing schema is painful and error-prone. The multi-tenant SaaS architecture guide explains the three patterns (database-per-tenant, schema-per-tenant, row-level security) and when to use each.
For most early-stage SaaS, row-level security in Postgres is the right default. Supabase makes this straightforward with built-in RLS policies.
Authentication
Use your framework's auth solution. For Supabase, that means supabase-auth. For Next.js without Supabase, NextAuth.js. Do not build your own auth — this is the most common source of security vulnerabilities in early-stage SaaS.
API Design
REST is fine for MVP. GraphQL adds complexity you do not need until you have multiple clients consuming the same API. Design endpoints around your UI flows, not around your data model.
Step 5: Build in the Right Order
This sequence has worked across multiple projects:
- Auth — login, signup, password reset, session management
- Core data model — the tables and relationships your product is built around
- Core workflow — the one thing your MVP is supposed to do
- Billing — Stripe subscription setup before you talk to any customer
- Email notifications — the bare minimum to make the product usable
- Basic UI polish — enough to not look broken, not enough to look finished
Billing before customers sounds counterintuitive. It is not. If you do not have billing working when a customer says "I want to sign up," you lose them. Integrate Stripe before your first demo.
Weekly Milestones
Week 1–2: Auth + data model Week 3–4: Core workflow Week 5–6: Billing + email Week 7–8: UI polish + staging environment Week 9–10: Beta users (5–10 people, not 100) Week 11–12: Iterate on feedback, fix critical bugs Week 12+: First paid plan launch
Twelve weeks is achievable for a solo developer or a two-person team. It requires saying no to every feature not on the MVP list.
Step 6: Agency vs. Freelancer vs. Build It Yourself
If you are not the technical founder, you need outside development help. The agency vs. freelancer comparison for SaaS MVPs covers this in detail.
Short version:
Hire a freelancer when: you have clear specs, a limited budget (€8,000–€20,000), and you can manage the project yourself.
Hire an agency when: you need a team (design + dev + QA), you want one point of accountability, or your product is complex enough to need architecture guidance upfront.
Build it yourself when: you are technical, you have time, and you want to keep equity. The learning curve is real but the control is worth it.
If you are evaluating outside help, I work with SaaS startups at the MVP stage — scoping, architecture, and full-stack development through to launch.
Step 7: First Customers Before Launch
Do not wait for a polished product to start selling. Your first 5 customers should come from conversations, not from a marketing website.
Find your ICP (ideal customer profile) in the communities where they already spend time — LinkedIn, Slack groups, Reddit threads, industry forums. Reach out personally. Offer access to the beta in exchange for feedback sessions.
Your goal at this stage is not revenue. It is learning. The conversations will reshape your product more than any amount of solo iteration.
Pricing for MVP
Set a price before you launch. Founders who say "it's free while in beta" train their users to expect free forever. Even a nominal €49/month filters out non-serious users and signals that this is a real product.
Use simple, flat pricing for MVP. One or two tiers maximum. Usage-based billing adds complexity you do not need until you understand your cost structure.
Step 8: Launch and Iterate
Launch is not a moment, it is a process. For SaaS MVPs, a "launch" means:
- Your product is accessible at a real domain
- Billing works
- You have at least 3 paying customers (even at friends-and-family pricing)
- You are actively collecting feedback
Post-launch, the job changes. You stop building new features and start listening. Every support ticket, every churned trial, every "I wish it could..." is a signal. Prioritize ruthlessly.
Track these metrics from day one:
- Trial-to-paid conversion rate (target: >15%)
- Monthly churn rate (target: <5%)
- Time to first value (how long before a new user completes the core workflow)
If trial-to-paid conversion is below 10%, the product is not solving the problem clearly enough, the onboarding is too friction-heavy, or you are attracting the wrong users.
What Kills SaaS MVPs
After building multiple products and talking to dozens of founders, the same failure patterns appear:
Over-scoping: Trying to solve every edge case before validating the core. Cut features ruthlessly. You can always add them back.
Building without talking to customers: Every week of development without customer conversations is a week of building assumptions. Validate constantly.
Waiting for perfect: Shipping a working MVP beats building a polished product nobody uses. Done beats perfect at the MVP stage.
Wrong co-founder fit: Technical + business is the classic combination. Two technical co-founders who cannot sell, or two business co-founders who cannot build, both struggle.
Ignoring unit economics: Know your cost to acquire a customer and your customer lifetime value before you raise money. Investors ask. You should know.
Summary
Building a SaaS MVP in 2025 is faster and cheaper than it has ever been — but only if you scope correctly, pick the right stack, and validate before you build.
The framework:
- Define the problem, not the product
- Scope to the minimum that delivers real value
- Pick a boring, proven stack (Next.js + Supabase + Stripe)
- Build in the right order (auth → data model → core workflow → billing)
- Get paying customers before you are "ready"
If you want to talk through your specific product or get an estimate on build cost, start a chat — I work with founders at this exact stage.