SaaS architecture is how your software is structured to serve multiple customers simultaneously, charge them reliably, and scale without breaking. You don’t need to understand the code — but understanding the concepts will make you a better founder, a sharper hiring manager, and a more effective communicator with your development team.
Here’s everything you need to know, in plain English.
What Makes SaaS Different From a Regular Website
A marketing website serves all visitors the same content. A SaaS application serves each user their own data, protected from every other user’s data, with their own account, subscription, and settings.
This requires:
- Authentication — knowing who someone is
- Authorization — controlling what they can see and do
- Multi-tenancy — keeping each customer’s data separate
- Billing — charging them correctly and reliably
- Infrastructure — keeping everything running as you grow
Multi-Tenancy: The Core SaaS Concept
Multi-tenancy means multiple customers (“tenants”) share the same application infrastructure. Your B2B SaaS might have 500 companies using it — they all run on the same servers, same database, same codebase. But each company’s data is completely invisible to the others.
There are three ways to build this:
Shared database, shared schema: All customers’ data lives in the same database tables. Each row has a tenant_id column. When your app queries data, it always filters by the current user’s tenant. Simple to build, good for early stage.
Shared database, separate schemas: All customers in the same database, but each gets their own set of tables (schema). More isolation, more complex to manage.
Separate databases per tenant: Each customer gets their own database. Maximum isolation. Very complex to operate. Only justified for enterprise customers with strict compliance requirements.
For most SaaS startups, shared database with tenant IDs is the right approach. Supabase makes this particularly clean with Row-Level Security (RLS) — database-level policies that automatically filter data to the current user’s tenant.
Authentication vs Authorization
People use these words interchangeably — they’re different things.
Authentication (AuthN): “Who are you?” — verifying identity. Email + password, magic link, Google OAuth. Handled by Clerk, Supabase Auth, or Auth.js.
Authorization (AuthZ): “What are you allowed to do?” — controlling access. “This user is an admin in their organization, so they can see the billing page.” “This user is a viewer, so they can’t delete records.”
For a simple SaaS, authorization is often just “logged in or not logged in.” As you add team features, roles (admin, member, viewer) become important. As you add enterprise features, it can become complex (custom permissions, resource-level access control).
The Database Layer
Your SaaS needs a database. For most products, this is PostgreSQL — the most widely used, most capable open-source relational database.
What goes in the database:
- User accounts and profiles
- Subscription and billing state
- Your product’s core data (whatever users create or store in your app)
- Audit logs (who did what, when)
Managed database options: Supabase, Neon, PlanetScale (MySQL), Railway PostgreSQL. These handle backups, scaling, and maintenance — you just connect and use.
The Billing Layer
Billing is one of the most complex parts of SaaS architecture. Get it wrong and you either don’t collect money (bad) or charge people incorrectly (worse — chargebacks and churn).
The standard approach: Stripe handles all money movement. Your database mirrors Stripe’s subscription state via webhooks.
When a user subscribes:
- They check out through Stripe Checkout
- Stripe creates a subscription and sends a webhook event to your app
- Your app receives the webhook, verifies it’s from Stripe, and updates the user’s
subscription_statusin your database - Your app checks
subscription_statuson every protected page/API route
When a payment fails, Stripe sends another webhook. Your app updates the subscription status and triggers a “payment failed” email.
This webhook-driven architecture is reliable but requires careful implementation. At Whipp Studio, we have a tested pattern for Stripe webhook handling that we deploy on every SaaS build.
Infrastructure: Where Your Code Runs
Frontend: Your user interface — the React/Next.js code that runs in users’ browsers. Hosted on Vercel (or Netlify, Cloudflare Pages).
Backend/API: The server-side logic that handles requests, queries the database, and processes business logic. For Next.js, this lives alongside the frontend in the same codebase. For separate backends, this runs on Railway, Render, or AWS.
Database: Your PostgreSQL database. Hosted on Supabase, Neon, or Railway.
File storage: User-uploaded files (images, documents, exports). Stored on Supabase Storage (S3-compatible) or AWS S3.
Email: Transactional emails (welcome, password reset, notifications). Sent via Resend or SendGrid.
Background jobs: Long-running tasks that shouldn’t block a web request (sending 10,000 emails, generating a large report, processing an uploaded file). Handled by Inngest or Trigger.dev.
How It All Works Together (An Example)
A user signs up for your SaaS:
- They fill in the signup form on your Next.js frontend
- Supabase Auth creates an account and sends a verification email
- Your app creates a
usersrecord in your PostgreSQL database withsubscription_status: 'trial' - A welcome email is sent via Resend
- The user verifies their email and logs in
- They choose a plan and enter payment info in Stripe Checkout
- Stripe processes the payment and sends a
customer.subscription.createdwebhook - Your webhook handler updates
subscription_status: 'active'in your database - The user now has access to all paid features
This entire flow, when built correctly, runs without your involvement. Users sign up and pay while you sleep.
Scaling: When to Worry About It
Don’t. Not yet.
The infrastructure described above — Vercel + Supabase + Stripe — handles tens of thousands of users without modification. Scaling problems at this level are good problems: they mean you have significant revenue.
Plan for scaling when you’re approaching $1M ARR and your database or API is showing real performance constraints. Before that, focus on building a product people love.
Frequently Asked Questions
Do I need a dedicated backend server for my SaaS? Not necessarily. Next.js API routes on Vercel handle backend logic for most SaaS products. A separate backend is warranted for complex processing, WebSockets at scale, or specific runtime requirements.
What’s the difference between a startup using shared infrastructure and an enterprise one? Enterprise features often require dedicated infrastructure (single-tenant), custom SLAs, SSO integration, and advanced audit logging. Most SaaS products don’t need this until they’re selling to large enterprises.
How does data backup work? Supabase automatically backs up your database daily (with point-in-time recovery on Pro plans). Vercel keeps deployment history. Configure daily exports of critical data as an additional safety net.
Can my SaaS be hacked? Any web application can be attacked. The main protections: Supabase RLS to prevent data leakage, HTTPS everywhere, parameterized database queries (prevent SQL injection), rate limiting on API endpoints, and security-conscious authentication flows. A good dev team builds these in by default.
What does it cost to run a SaaS product per month? Under $100/month until you have thousands of active users: Vercel Pro ($20), Supabase Pro ($25), Resend ($20), Sentry free tier ($0). Scale these as you grow.
Need someone to build this architecture for you? At Whipp Studio, this is exactly what we do — full SaaS builds from database design to deployed product. Book a free strategy call →