Most SaaS guides tell you to "find a problem worth solving" and then skip straight to launch metrics. This one doesn't. This is the guide I'd want to read before building a SaaS product — the practical decisions that actually determine whether you ship something that works.
I've been building SaaS products since 2017 — as an agency that has built dozens of them for founders across the US, UK, and Australia. Some of those products are now live, revenue-generating businesses. Some never made it past the first 100 users. The difference between them was rarely the idea. It was almost always the decisions made in the first six months.
Here's what those decisions actually look like.
Step 1: Validate the problem before writing a line of code
Every SaaS founder is convinced their idea is good. Most of them are wrong — not about the problem existing, but about whether people will pay to solve it in the way they've imagined.
Validation before development means finding evidence that real people will pay for your solution, not just that they have the problem you're describing.
What validation actually looks like:
Talk to 20 people who have the problem. Not friends. Not family. Not people who will be encouraging to be polite. People who currently deal with this problem in a professional context and have incentive to be honest.
Ask them:
- How do you currently solve this problem?
- How much time does it take?
- What do you spend on solving it today (tools, staff time, outsourcing)?
- What would it be worth to you to solve it better?
- Would you pay $X/month for a tool that did Y?
The answers to the last two questions are where most ideas die. A problem that people solve with 20 minutes of spreadsheet work per week is not a problem that justifies a $99/month subscription. A problem that costs a business $5,000/month in staff time absolutely is.
The pre-launch landing page test:
Before building anything, build a landing page that describes your product as if it exists. Include a pricing page. Add a "Start Free Trial" or "Join Waitlist" button. Drive traffic to it — through LinkedIn posts, relevant communities, direct outreach to target customers. Measure how many people click the sign-up button.
People clicking a sign-up button for a product that doesn't exist yet is the closest thing to validation you can get without actually shipping. It's not perfect — people click things they'd never pay for. But it's significantly better than building for six months and discovering nobody wants it.
The letter of intent:
For B2B SaaS, the ultimate validation is a letter of intent — a non-binding commitment from a potential customer that they will pay for your product when it's ready. Even five LOIs from relevant companies at your target price point is evidence that your SaaS idea has real commercial potential.
Step 2: Define your MVP with discipline
An MVP is not a minimum version of your full product. It's the smallest thing you can build that delivers core value to a specific user and generates market signal.
Most founders scope their MVP at roughly 2–3x what it should be. I've seen this enough times to know it's almost universal. The features that feel essential at the planning stage are frequently not what users actually need first.
The MVP scoping exercise:
List every feature you think your MVP needs. Then ask, for each feature: if we removed this feature, could we still validate whether people will pay for the core value proposition?
Features that pass this test: remove from MVP, add to v2. Features that fail this test: include in MVP.
For most B2B SaaS products, a properly scoped MVP includes:
- Authentication (signup, login, password reset)
- Core workflow — the one thing users absolutely need to do to get value
- Basic data persistence and retrieval
- The ability for users to invite colleagues (for team products)
- Stripe billing (so you can actually charge from day one)
- A way to receive and respond to user feedback
Everything else — advanced reporting, API access for enterprise customers, mobile apps, complex notification systems, deep integrations — is v2 and beyond.
The timeline reality:
A properly scoped SaaS MVP takes 12–20 weeks to build with a professional development team. Less than 12 weeks typically means corners were cut. More than 20 weeks typically means scope creep happened.
If your MVP will take longer than 20 weeks, your MVP is too big.
Step 3: Decide who builds it
Three realistic options for building a SaaS product:
Option A: Build it yourself (if you're technical)
Fastest to start, slowest to scale. You control everything and spend nothing on development. You also spend every hour building instead of selling, and you probably ship slower than you think because building a production SaaS product alone is significantly harder than building personal projects.
Right for: technical founders who want to validate the idea before raising money or bringing on a development partner.
Option B: Hire in-house developers
Most expensive. Takes 3–4 months to find and close candidates in competitive markets. Creates long-term employment obligations before you've validated the business.
Right for: funded companies that have validated the business model and are scaling engineering.
Option C: Work with a development agency
Faster to start than hiring. More expensive per hour than in-house long-term but lower fixed cost and no hiring overhead. Quality varies enormously — the difference between the right agency and the wrong one is the difference between shipping a product and spending your budget on something unusable.
Right for: pre-seed and seed founders who need to ship faster than they can hire and want to maintain equity by avoiding co-founders for technical reasons.
How to choose an agency:
If you go the agency route — which most early-stage SaaS founders should — the selection process matters more than any other decision you'll make in the first six months.
The three things that actually predict a good SaaS agency engagement:
They have built SaaS products before — not just websites, not just mobile apps, but multi-tenant SaaS with billing, user management, and the specific architecture challenges of B2B products.
Their process starts with your business, not your features — good agencies spend significant time understanding the problem before proposing a solution. An agency that quotes a fixed price within 24 hours of reading your brief didn't read it carefully.
You can speak to references from similar projects — not generic software references, but founders who built a SaaS product with this agency. Call them. Ask specifically whether the product was delivered as specified, on time, and on budget.
Step 4: Make the right architecture decisions early
The architecture decisions made in the first month of SaaS development are the most expensive to change later. Two matter more than any others:
Decision 1: Multi-tenancy model
Multi-tenancy is how your SaaS serves multiple customers from the same infrastructure. For B2B SaaS, this is not optional — it's the defining characteristic of the product.
The three models:
Shared database, shared schema: Every customer's data in the same tables, distinguished by a tenant_id column. Simplest to build. Cheapest to operate. Requires careful application-level isolation or you risk data leakage between customers.
Shared database, separate schemas: Each customer gets their own database schema. Stronger isolation. More complex migrations. Good middle ground for mid-market SaaS.
Separate databases: Complete isolation. Most expensive to operate. Required by some enterprise customers with strict data sovereignty requirements.
For most early-stage SaaS products: start with shared database, shared schema, add PostgreSQL Row Level Security as a safety net against accidental cross-tenant data access. Plan the migration path to separate schemas when you start winning enterprise customers.
Decision 2: Authentication approach
Don't build authentication yourself. The implementation isn't hard — maintaining it is. Token rotation, session management, MFA, SSO for enterprise customers, breach detection, OAuth providers — the ongoing engineering investment of maintaining custom authentication adds up to months of work per year.
Use an authentication service: Auth0, Clerk, Supabase Auth, or AWS Cognito. The monthly cost is almost always lower than the engineering time to maintain equivalent functionality.
The one exception: if your authentication requirements are unusual enough that no service handles them, or if you're in a regulated industry where third-party authentication creates compliance problems.
Step 5: Build billing correctly from day one
Billing is the most underestimated component of SaaS development. "We'll just use Stripe" is true — Stripe is the right choice for most SaaS products. But Stripe integration and billing done properly are not the same thing.
What billing done properly includes:
Subscription lifecycle management: new subscriptions, trial periods, trial-to-paid conversion, upgrades, downgrades, cancellations, reactivations. Each of these is a state your application needs to handle correctly.
Failed payment handling: cards expire, charges fail for various reasons. You need a dunning process — retry the charge on a schedule, notify the customer via email, downgrade access after a defined period, allow reactivation after payment is updated.
Proration: if a customer upgrades from a $50/month plan to a $100/month plan on day 15 of a 30-day cycle, what do they owe? Stripe handles the calculation, but your application needs to handle the state change and communicate it clearly to the customer.
Invoice customisation: enterprise customers frequently need specific billing entity names, purchase order numbers, tax identification numbers on invoices. Collecting these and passing them to Stripe correctly is more than one afternoon of work.
Usage-based billing (if applicable): if your pricing model includes anything based on usage — API calls, active users, storage, seats — you need a metering system that accurately tracks and reports usage to Stripe. This is its own engineering project.
Start with the simplest billing model your business can support and add complexity only when a real customer requires it.
Step 6: Plan your launch before you start building
The biggest mistake SaaS founders make is treating launch as the end of the product development process. It's the beginning of a different process — customer acquisition and retention — that should be designed in parallel with the product.
By the time you ship v1, you should already have:
A waitlist with at least 200 people on it. Building in public on LinkedIn, writing about the problem you're solving, engaging in communities where your target customers spend time — this generates a list of people who are warm to your product before it exists. Launching to 200 interested people is very different from launching to an empty room.
5 design partners. Design partners are early customers who agree to use your product during development, give you regular feedback, and potentially pay reduced rates in exchange for influence on the roadmap. They give you real-world validation of your assumptions before launch and make compelling case studies afterward.
A pricing strategy you've actually tested. Show your pricing page to potential customers before launch. Ask if the price feels right. Ask what they'd need to see to justify the price. Pricing is easier to set correctly before you have customers than to change after you have customers who are anchored to a price.
A customer success process. How will new customers get set up? What's your onboarding flow? Who do they contact when they have problems? What does the first 30 days look like? The SaaS products that retain customers do this deliberately. The ones that churn build the product and figure out onboarding later.
Step 7: The first 90 days after launch
The period immediately after launch is where most SaaS products fail — not because the product doesn't work, but because the founder doesn't know how to use early user behavior to make the product better.
Talk to every user in the first 30 days. Not through surveys. By phone or video call. Ask them: what made you sign up? What are you trying to do? What's confusing? What's missing? This is the most valuable time you will ever spend in your company — users who leave in the first 30 days leave forever, and the reasons they leave are almost always fixable if you find out what they are.
Measure the right things. Vanity metrics — signups, page views, total users — tell you almost nothing in the early stage. The metrics that matter:
- Activation rate: what percentage of signups complete the core action that delivers value?
- Day 7 retention: what percentage of users are still using the product 7 days after signing up?
- Day 30 retention: same question at 30 days
- Time to value: how long from signup until a user first experiences the core value?
If activation rate is below 50% or Day 7 retention is below 40%, there's a product problem to fix before spending on acquisition.
Don't optimise acquisition before you have retention. This is the most common mistake post-launch SaaS founders make. Spending on ads, hiring sales people, and building growth loops before you've proven that users who try your product actually keep using it is throwing money away. Fix retention first.
What a realistic SaaS launch looks like
Not the hockey-stick graph. The realistic one.
Month 1: 20–50 users, mostly from your waitlist and network. 30–50% churning because the product doesn't fit their workflow yet.
Month 2–3: First paying customers (typically 5–15). Product iteration based on real user feedback. First glimpses of what's working and what isn't.
Month 4–6: Finding the wedge — the specific type of customer who activates, pays, and stays. This is your actual target customer, who is often somewhat different from who you imagined in month 1.
Month 6–12: Growth starting to compound as you double down on what's working. Retention improving as you fix the product for your actual customer.
Month 12+: Real traction if you got through the first year.
This is not discouraging — this is what the successful ones look like. The founders who navigate this well are the ones who stay close to customers, iterate on the product honestly, and don't mistake early growth metrics for validation.
Muhammad Nabeel is the co-founder of Teamseven, a SaaS development agency based in Lahore, Pakistan. We've been building SaaS products for founders across the US, UK, and Australia since 2017. Get in touch if you're building a SaaS product and want to talk through the approach.