If you are figuring out how to build a SaaS product, you have probably noticed that most guides are just generic software advice with "SaaS" in the title. This is not that post. We are skipping the basics and covering the SaaS specific technical decisions that determine whether your product scales or collapses: multi tenancy architecture, subscription billing, onboarding that reduces churn, and usage metering that does not lie to your customers.
Multi Tenancy: The First Decision That Shapes Everything
Before you write a single line of product code, decide how you are isolating customer data. This is a foundational architecture decision that is extremely expensive to change later.
Shared database with tenant isolation, every table has a `tenant_id` column, and every query filters by it. The right choice for 99% of early stage SaaS products. Efficient to deploy, back up, and query across tenants. The risk is a missing `WHERE tenant_id = ?` leaking data. The mitigation: Row Level Security (RLS), database level policies that enforce isolation regardless of application code. On Postgres, RLS is built in and battle tested.
Schema per tenant, each customer gets their own schema. Stronger isolation without the operational overhead of separate databases. Works for white label platforms with slightly different data models. Downside: migrations run across hundreds of schemas.
Database per tenant, full isolation for enterprise compliance requirements (healthcare, finance, government). Operationally expensive, you are managing N databases.
Our recommendation: start with shared database + RLS. Migrate high value enterprise customers to isolated databases later. Do not over engineer isolation on day one.
Subscription Billing: Use Stripe and Move On
Use Stripe Billing. It handles recurring charges, prorations, trials, tax calculation, invoicing, and dunning management. Building any of this yourself is a mistake. We have built payment systems across multiple products, every team that rolled their own billing eventually migrated to Stripe.
What you need to build is the webhook integration layer:
- `customer.subscription.created`, provision the tenant, set plan limits, trigger onboarding
- `customer.subscription.updated`, adjust feature access for upgrades/downgrades
- `invoice.payment_failed`, enter grace period, notify customer, restrict access progressively
- `customer.subscription.deleted`, deactivate account, retain data for reactivation window
Dunning management is what most founders forget. When payment fails, Stripe retries automatically. Your job is the degraded experience, what does the customer see on day 1 of failure versus day 14? Progressive restriction (read only, then lockout) recovers more revenue than immediate cancellation.
For how billing complexity affects overall project costs, see our pricing breakdown.
Onboarding and Activation: The First 5 Minutes
Your churn rate is largely determined by what happens in the first five minutes after signup. If a new user lands on an empty dashboard, most will leave forever.
Seed data scripts, populate new accounts with realistic sample data. Not lorem ipsum. A project management SaaS should show a sample project with tasks and deadlines. The user should see the product working before they configure anything.
Progressive disclosure with feature flags, do not show every feature on day one. Track activation milestones per tenant and unlock interface elements as users complete key actions. Store activation state in a JSON column on the tenant record.
Progress indicators, "3 of 7 steps complete" creates completion bias that drives users through activation. Track server side so it persists across sessions.
Usage Metering and Limits
If your pricing involves usage based components, API calls, seats, storage, messages, you need real time metering. Getting this wrong means giving away free usage or overcharging customers.
Event ingestion, every billable action writes to a metering table: `tenant_id`, `metric_type`, `quantity`, `timestamp`. Do not aggregate in real time. Write raw events, compute totals asynchronously.
Background aggregation, a scheduled job rolls up raw events into period summaries. These drive both customer facing dashboards and Stripe's usage reporting API.
Rate limiting and overage handling, when a tenant approaches limits, enforce at the API level. Decide your policy: hard cutoff (block requests), soft limit (charge extra), or throttle (degrade performance). Hard cutoffs are simpler and easier for customers to understand.
Critical detail: metering must be eventually consistent but never lose events. Use a write ahead pattern, write to a durable queue first, then process. Losing metering events means lost revenue.
The MVP SaaS Stack: Ship in 6-8 Weeks
Stop evaluating. Here is the stack:
- Next.js, frontend and API layer. SSR for marketing pages, client side app for dashboard. One codebase, one deployment.
- Supabase, Postgres with RLS for tenant isolation, authentication, and real time subscriptions. Skip building auth entirely.
- Stripe Billing, subscription management, invoicing, dunning, tax. Connect with webhooks and never think about billing infrastructure again.
- Resend, transactional email for onboarding sequences, receipts, and alerts. Simple API, reliable delivery.
This gives you multi tenancy with RLS, auth, subscription billing, and email out of the box. Your engineering time goes toward your actual product, not infrastructure. We use this exact stack for full stack SaaS development and it consistently delivers production MVPs in 6-8 weeks. Our SaaS playbook covers the specific decisions this stack enables.
Build Your SaaS With a Team That is Done It
The decisions above, multi tenancy, billing, onboarding, metering, are ones we have made dozens of times. If you want to skip the learning curve and ship your SaaS MVP on a proven stack, tell us about it →