SaaS Application
Build and launch a multi-tenant SaaS product from planning to growth.
Phase Navigation
Planning & Architecture
Define scope, choose tech stack, design data model and multi-tenant architecture.
Why
SaaS planning determines your scalability ceiling, cost structure, and team velocity for years. Getting the multi-tenant model, billing, and data isolation right at the start avoids painful migrations later. A wrong stack choice can cost 6+ months of rework.
When
Before writing any production code. Typically 2-4 weeks for a small team, 1-2 months for complex products. Skip planning only for throwaway prototypes.
How
1. Define the problem and target user
- Write a 1-page PRD: problem, target user, core workflow, success metric
- List 5 must-have features for MVP; park everything else
2. Choose the tech stack
- Frontend: Next.js/Remix (SSR for SEO + fast interactivity)
- Backend: Node.js or Python (pick what your team knows best)
- Database: PostgreSQL (multi-tenant ready, JSONB for flexibility)
- Auth: Clerk/Auth0 (don't build auth yourself)
- Hosting: Vercel/Fly.io (auto-scale, pay-per-use)
3. Design multi-tenant architecture
- Shared database, shared schema (row-level tenant_id) — simplest, scales to ~1000 tenants
- Shared database, separate schemas — better isolation, moderate complexity
- Separate databases — strongest isolation, highest operational cost
4. Design data model
- Core entities: Tenant, User, Subscription, BillingEvent
- Every table gets a tenant_id column + index
- Use UUIDs for public-facing IDs (no sequential leaking)
5. Plan billing and limits
- Choose pricing model: per-seat, per-usage, or tiered
- Integrate Stripe from day 1 (hard to retrofit)
- Define rate limits per plan tier
Example
PRD: Task management for small dev teams
Target: 5-50 person engineering teams
MVP features: boards, tasks, comments, 1 integration (GitHub)
Stack: Next.js + tRPC + PostgreSQL + Clerk + Vercel
Multi-tenant: shared schema with tenant_id on every table
Schema sketch:
tenants (id, name, plan, stripe_customer_id)
users (id, tenant_id, email, role)
projects (id, tenant_id, name)
tasks (id, tenant_id, project_id, assignee_id, status)
Billing: Stripe + per-seat ($10/user/month)
Rate limits: Free=3 projects, Pro=unlimited, Enterprise=SSO+audit
Common Problems
- ⚠Over-engineering: building for 10K tenants when you have 0 — start with shared schema
- ⚠Skipping billing: retrofitting Stripe into an existing app is 2-4 weeks of pain
- ⚠No tenant isolation in queries: one missing WHERE tenant_id = ? leaks data across tenants
- ⚠Choosing bleeding-edge tech: unproven frameworks cost more in debugging than they save
Best Practices
- ✓Write the PRD before choosing the stack — tech follows requirements, not vice versa
- ✓Enforce tenant_id at the ORM/query-builder level, not in every hand-written query
- ✓Integrate Stripe in week 1, even if pricing is TBD — the data model needs it
- ✓Use feature flags from day 1 to decouple deploy from release
Resources for this stage
Tools
AI Assistance
Development & Testing
Build the MVP with CI/CD, automated tests, and progressive enhancement.
Why
SaaS development is a marathon, not a sprint. Without CI/CD and test coverage from week 1, technical debt compounds rapidly. Each untested feature becomes a liability when you have paying customers who expect 99.9% uptime.
When
After planning is complete. Typically 3-6 months for MVP. Start with the riskiest features first (billing, multi-tenancy) to validate assumptions early.
How
1. Set up CI/CD from day 1
- GitHub Actions: lint + type-check + test on every PR
- Auto-deploy to staging on merge to main
- Manual promote to production
2. Build core features in priority order
- Auth + tenant onboarding (week 1-2)
- Core domain features (week 2-8)
- Billing integration (week 8-10)
- Polish + edge cases (week 10-12)
3. Write tests alongside features
- Unit tests for business logic (aim for 80%+ coverage)
- Integration tests for API endpoints
- E2E tests for critical paths (signup, payment, core workflow)
- Run full suite on every PR (< 5 min target)
4. Implement progressive enhancement
- Server-rendered HTML works without JS
- Hydrate interactive elements progressively
- Loading states for all async operations
- Error boundaries at every route segment
5. Set up observability
- Error tracking: Sentry (free tier covers early stage)
- Analytics: PostHog (self-hostable, product analytics)
- Uptime monitoring: Better Stack or UptimeRobot
Example
CI pipeline (.github/workflows/ci.yml):
on: pull_request
jobs:
- lint (eslint --max-warnings=0)
- type-check (tsc --noEmit)
- test (vitest run --coverage)
- e2e (playwright test --shard=1/3)
all must pass before merge
Test structure:
src/__tests__/unit/ — business logic
src/__tests__/integration/ — API endpoints
e2e/critical-paths.spec.ts — signup, payment, core flow
Deployment:
PR merge -> staging (auto)
Tag release -> production (manual approve)
Rollback: vercel rollback (30 seconds)
Common Problems
- ⚠No CI for the first 3 months — every deploy is a gamble with manual testing
- ⚠Testing only happy paths — edge cases (empty state, concurrent edits, payment failures) break in production
- ⚠Monolith without module boundaries — changes in one area break unrelated features
- ⚠No error tracking — customers report bugs before you know they exist
Best Practices
- ✓CI must run in < 5 min — developers will skip long CI by pushing directly to main
- ✓Test the billing flow with Stripe test mode end-to-end, including webhooks and failures
- ✓Deploy small, deploy often — 10 deploys/week of small changes beats 1 big Friday deploy
- ✓Set up Sentry on day 1 — you need to know about errors before customers do
Launch & Growth
Ship to production, acquire first customers, and instrument growth metrics.
Why
Launch is where assumptions meet reality. Without proper instrumentation, you cannot distinguish between 'product doesn't work' and 'marketing doesn't work'. The first 100 paying customers validate your entire thesis — get to them fast.
When
When MVP is feature-complete and CI/CD is green. Don't wait for perfection — launch at 80% and iterate based on real feedback.
How
1. Pre-launch checklist
- Production environment tested with real data
- DNS + SSL configured (Cloudflare in front)
- Privacy policy + terms of service live
- Support channel ready (email or Intercom)
- Analytics + error tracking verified
2. Soft launch (friends & family)
- Invite 20-50 friendly users
- Watch for critical bugs and UX confusion
- Conduct 30-min interviews with each user
- Fix blocking issues before public launch
3. Public launch
- Post on Product Hunt, Hacker News, relevant subreddits
- Write a launch blog post with your 'why'
- Offer early-adopter pricing (50% off first 3 months)
- Have a demo video or interactive walkthrough
4. Instrument growth metrics
- AARRR funnel: Acquisition, Activation, Retention, Revenue, Referral
- Define activation event (e.g., 'created first project')
- Track conversion at each step weekly
- Set up cohort retention table
5. Iterate based on data
- Weekly review: what's the biggest leak in the funnel?
- Fix one thing per week, measure impact
- Talk to 5 churned users per month — their reasons are your roadmap
Example
Launch day checklist:
[x] Production deploy: v1.0.0
[x] Cloudflare DNS + SSL: active
[x] /privacy and /terms: live
[x] support@company.com: monitored
[x] Sentry + PostHog: receiving events
[x] Stripe: live mode (not test)
Metrics dashboard (PostHog):
Acquisition: unique visitors from launch sources
Activation: % who created first project within 24h
Retention: D7, D30 cohort retention
Revenue: MRR, ARPU, churn rate
Referral: invites sent / accepted
Week 1 results:
2000 visitors, 200 signups, 80 activated, 12 paid
Biggest leak: signup -> activation (60% drop)
Action: simplify onboarding, add empty-state templates
Common Problems
- ⚠Launching without analytics — you can't fix what you can't measure
- ⚠Big bang launch to 10K users — server crashes, first impression ruined
- ⚠No activation definition — 'signups' is a vanity metric, not a growth signal
- ⚠Ignoring churned users — they have the most valuable feedback but nobody talks to them
Best Practices
- ✓Define activation before launch — it's the metric that predicts long-term success
- ✓Soft launch to 20 users first — fix critical issues before thousands see them
- ✓Track AARRR weekly — a 1% improvement at each step compounds to 50%+ revenue growth
- ✓Call 5 churned users per month — qualitative feedback guides quantitative fixes
Full Developer Lifecycle
A 14-stage developer roadmap from idea to maintenance — visualize dependencies and track progress.
Next Step