Appearance
Anatomy of a SaaS Product
A modern SaaS product is a layered system of interconnected components — from the interface users see to the infrastructure they never think about — each layer serving a distinct purpose.
Why This Matters
- 🏢 Owner: Understanding the technical anatomy helps you make informed build-vs-buy decisions, estimate costs, hire the right engineers, and avoid costly architectural mistakes that surface at scale.
- 💻 Dev: This is your domain. Knowing how all layers connect — and which trade-offs matter at each lifecycle stage — is the difference between building something that scales and building something that breaks.
- 📋 PM: You don't need to code, but you need to understand what's technically feasible, what's expensive, and where the bottlenecks are. This knowledge makes you a dramatically better PM.
- 🎨 Designer: The frontend architecture constrains and enables your design. Understanding API contracts, loading states, real-time updates, and offline behavior helps you design experiences that are actually buildable.
The Concept (Simple)
Think of a SaaS product like a restaurant:
- Frontend = The dining room. What customers see, touch, and interact with. The menu, the plates, the ambiance.
- API Layer = The waitstaff. They take orders from the dining room and relay them to the kitchen. They translate between "customer language" and "kitchen language."
- Backend Services = The kitchen. Where the real work happens — cooking, preparing, combining ingredients into meals.
- Database = The pantry and recipe book. All ingredients (data) and instructions (schemas) are stored here.
- Auth/Identity = The front door and reservation system. Verifying who you are and what table you can sit at.
- Billing/Payments = The cash register. Tracking what you ordered, what you owe, and processing payment.
- Infrastructure = The building itself. Plumbing, electricity, gas lines, ventilation. Nobody notices it until it breaks.
- Monitoring = The security cameras and smoke detectors. Watching everything so problems get caught early.
How It Works (Detailed)
The Complete SaaS Architecture
┌─────────────────────────────────────────────────────────────────────────┐
│ USERS / CUSTOMERS │
│ (Browser, Mobile App, API Client) │
└───────────────────────────────┬─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────┐
│ CDN / EDGE LAYER │
│ (Cloudflare, Fastly, AWS CloudFront) │
│ Static assets, caching, DDoS protection, SSL │
└───────────────────────────────┬─────────────────────────────────────────┘
│
┌───────────────┴────────────────┐
│ │
▼ ▼
┌──────────────────────────┐ ┌──────────────────────────────────────────┐
│ FRONTEND │ │ API GATEWAY │
│ │ │ (Kong, AWS API GW, │
│ ┌────────────────────┐ │ │ custom reverse proxy) │
│ │ Web App (SPA) │ │ │ │
│ │ React / Vue / │ │ │ - Rate limiting │
│ │ Next.js / Svelte │ │ │ - Request routing │
│ └────────────────────┘ │ │ - API versioning │
│ │ │ - Request/response transform │
│ ┌────────────────────┐ │ └──────────────────┬───────────────────────┘
│ │ Mobile App │ │ │
│ │ React Native / │ │ │
│ │ Swift / Kotlin │ │ │
│ └────────────────────┘ │ │
└──────────────────────────┘ │
│
▼
┌─────────────────────────────────────────────────────────────────────────┐
│ BACKEND SERVICES │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Auth │ │ Core │ │ Billing │ │ Notif. │ │ Search/ │ │
│ │ Service │ │ Business │ │ Service │ │ Service │ │ Analytics│ │
│ │ │ │ Logic │ │ │ │ │ │ │ │
│ │ - Login │ │ - CRUD │ │ - Plans │ │ - Email │ │ - Index │ │
│ │ - SSO │ │ - Rules │ │ - Usage │ │ - Push │ │ - Query │ │
│ │ - RBAC │ │ - Work- │ │ - Invoic │ │ - In-app │ │ - Report │ │
│ │ - MFA │ │ flows │ │ - Stripe │ │ - SMS │ │ - Export │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │ │ │
└───────┼─────────────┼─────────────┼─────────────┼─────────────┼───────┘
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ DATA LAYER │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌────────────┐ │
│ │ Primary DB │ │ Cache │ │ Object │ │ Message │ │
│ │ (Postgres, │ │ (Redis, │ │ Storage │ │ Queue │ │
│ │ MySQL) │ │ Memcached) │ │ (S3, GCS) │ │ (SQS, │ │
│ │ │ │ │ │ │ │ Kafka) │ │
│ │ - User data │ │ - Sessions │ │ - Files │ │ - Async │ │
│ │ - Business │ │ - Hot data │ │ - Uploads │ │ jobs │ │
│ │ records │ │ - Rate │ │ - Backups │ │ - Events │ │
│ │ - Billing │ │ limits │ │ - Exports │ │ - Webhooks│ │
│ └──────────────┘ └──────────────┘ └──────────────┘ └────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
│ │
▼ ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ INFRASTRUCTURE LAYER │
│ │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────────┐ │
│ │ Compute │ │ Container │ │ CI/CD │ │ Monitoring │ │
│ │ (EC2, GCE, │ │ Orch. │ │ (GitHub │ │ (Datadog, │ │
│ │ Lambda) │ │ (K8s, ECS)│ │ Actions, │ │ Grafana, │ │
│ │ │ │ │ │ GitLab) │ │ PagerDuty) │ │
│ └────────────┘ └────────────┘ └────────────┘ └────────────────┘ │
│ │
│ Cloud Provider: AWS / GCP / Azure / Hybrid │
└─────────────────────────────────────────────────────────────────────────┘Layer-by-Layer Deep Dive
1. Frontend (The User Interface)
The frontend is everything the user directly sees and interacts with. In modern SaaS, this is typically a Single Page Application (SPA) running in the browser and/or a native mobile app.
What it does:
- Renders the UI (pages, forms, dashboards, tables)
- Handles user input and interaction
- Communicates with the backend via API calls
- Manages client-side state (what's selected, what's open, form data)
- Provides real-time updates (WebSockets, Server-Sent Events)
Technology choices:
| Framework | Best For | Used By |
|---|---|---|
| React | Complex UIs, large ecosystem | Facebook, Airbnb, Slack |
| Next.js | SEO + app hybrid, full-stack | Vercel, Notion website |
| Vue | Gentle learning curve | GitLab, Alibaba |
| Svelte/Kit | Performance-first apps | StackBlitz, Apple (?) |
| React Native | Cross-platform mobile | Discord, Shopify |
| Flutter | Cross-platform mobile | Google Pay, BMW |
For non-technical readers: The frontend is like the dashboard of a car. You see the speedometer, turn the steering wheel, and press pedals. You don't see the engine, transmission, or fuel system — but they're doing the real work behind the scenes.
For developers: At the MVP stage, pick a framework your team knows and ship fast. Don't over-architect. A well-structured Next.js or React app with a component library (shadcn/ui, Radix, Chakra) gets you to market fast. Worry about micro-frontends and design systems later. See the SaaS Lifecycle for when to invest in what.
2. API Layer (The Contract Between Frontend and Backend)
The API layer defines how the frontend (and external integrations) communicate with your backend services. It is the contract between consumers and producers of data.
API REQUEST/RESPONSE FLOW
=========================
Client API Gateway Backend Service
│ │ │
│ POST /api/v1/tasks │ │
│ { "title": "..." } │ │
│ ────────────────────────▶│ │
│ │ Validate token │
│ │ Check rate limit │
│ │ Route to service │
│ │ ────────────────────────▶│
│ │ │ Process
│ │ │ Validate
│ │ │ Save to DB
│ │ { id: 42, ... } │
│ │ ◀────────────────────────│
│ 200 OK │ │
│ { id: 42, ... } │ │
│ ◀────────────────────────│ │
│ │ │Common API styles:
| Style | Best For | Complexity | Example |
|---|---|---|---|
| REST | CRUD operations, simple APIs | Low | Stripe, Twilio |
| GraphQL | Complex frontends, mobile apps | Medium | GitHub, Shopify |
| gRPC | Service-to-service, high perf | High | Internal comms |
| WebSocket | Real-time updates, collaboration | Medium | Slack, Figma |
For non-technical readers: APIs are like a menu at a restaurant. The menu lists what you can order (endpoints), what information you need to provide (parameters), and what you'll get back (response). The kitchen doesn't care if you're ordering from the dine-in table or Uber Eats — the menu (API) is the same.
For developers: Start with REST. It's simple, well-understood, and every tool supports it. Add GraphQL only if your frontend has complex data requirements with lots of nested relationships. Use WebSockets for real-time features (live cursors, chat, notifications). Version your API from day one (/api/v1/) — it costs nothing now and saves you from breaking changes later.
3. Backend Services (The Business Logic)
This is where the core logic of your application lives. It processes requests, enforces business rules, orchestrates workflows, and manages data.
Architecture evolution by stage:
MVP Stage Growth Stage Scale Stage
────────── ──────────── ──────────
┌──────────────┐ ┌──────────────┐ ┌────────────────┐
│ MONOLITH │ │ MODULAR │ │ MICROSERVICES │
│ │ │ MONOLITH │ │ │
│ Everything │ ──▶ │ ┌──────────┐ │ ──▶ │ ┌────┐ ┌────┐ │
│ in one app │ │ │ Module A │ │ │ │Svc1│ │Svc2│ │
│ │ │ ├──────────┤ │ │ └────┘ └────┘ │
│ Rails/ │ │ │ Module B │ │ │ ┌────┐ ┌────┐ │
│ Django/ │ │ ├──────────┤ │ │ │Svc3│ │Svc4│ │
│ Express │ │ │ Module C │ │ │ └────┘ └────┘ │
│ │ │ └──────────┘ │ │ │
└──────────────┘ └──────────────┘ └────────────────┘
Team: 2-5 devs Team: 5-20 devs Team: 20-100+ devs
Deploy: 1 unit Deploy: 1 unit Deploy: independently
Complexity: Low Complexity: Medium Complexity: HighFor non-technical readers: The backend is the kitchen of your restaurant. It receives orders (API requests), follows recipes (business logic), pulls ingredients from the pantry (database), and sends completed dishes back. A small restaurant has one kitchen with one chef who does everything. A large restaurant has specialized stations — grill, pastry, sauces — each run by a specialist. That's the monolith-to-microservices evolution.
For developers: Start with a monolith. Seriously. A well-structured monolith in Rails, Django, Laravel, or Express gets you to $5M ARR. Extract services only when you have a specific scaling bottleneck or when a team needs to deploy independently. Premature microservices is the #1 architecture mistake in early SaaS. See SaaS Business Models for how your model influences backend needs.
4. Database (The Source of Truth)
Your database stores all customer data, application state, and business records. It is the most critical component — everything else can be rebuilt; lost data cannot.
Common database types in SaaS:
| Type | Technology | Used For |
|---|---|---|
| Relational (SQL) | PostgreSQL, MySQL | Core business data, transactions |
| Document (NoSQL) | MongoDB, DynamoDB | Flexible schemas, rapid prototyping |
| Key-Value | Redis, Memcached | Caching, sessions, rate limiting |
| Search | Elasticsearch | Full-text search, log analysis |
| Time-Series | InfluxDB, TimescaleDB | Metrics, usage data, analytics |
| Graph | Neo4j | Relationship-heavy data |
Multi-tenancy database strategies:
┌─────────────────────────────────────────────────────────────┐
│ DATABASE MULTI-TENANCY MODELS │
├─────────────────────┬─────────────────┬─────────────────────┤
│ SHARED DATABASE │ SHARED DB, │ SEPARATE DATABASE │
│ SHARED SCHEMA │ SEPARATE │ PER TENANT │
│ │ SCHEMAS │ │
│ ┌───────────────┐ │ ┌─────────────┐ │ ┌─────┐ ┌─────┐ │
│ │ users │ │ │ tenant_a. │ │ │DB_A │ │DB_B │ │
│ │ ┌───┬────────┐│ │ │ users │ │ │ │ │ │ │
│ │ │id │tenant_id││ │ ├─────────────┤ │ └─────┘ └─────┘ │
│ │ │ 1 │ A ││ │ │ tenant_b. │ │ ┌─────┐ │
│ │ │ 2 │ B ││ │ │ users │ │ │DB_C │ │
│ │ │ 3 │ A ││ │ └─────────────┘ │ │ │ │
│ │ └───┴────────┘│ │ │ └─────┘ │
│ └───────────────┘ │ │ │
│ │ │ │
│ ✅ Simple │ ✅ Isolation │ ✅ Full isolation │
│ ✅ Cost-effective │ ✅ Easy backup │ ✅ Compliance │
│ ⚠️ Must enforce │ ⚠️ More complex │ ⚠️ Expensive │
│ tenant_id filter │ ⚠️ Migration │ ⚠️ Hard to manage │
│ ⚠️ Noisy neighbor │ complexity │ at scale │
│ │ │ │
│ Best for: │ Best for: │ Best for: │
│ SMB, low ACV │ Mid-market │ Enterprise, │
│ │ │ regulated │
└─────────────────────┴─────────────────┴─────────────────────┘For non-technical readers: The database is your filing cabinet. Every piece of information — user accounts, settings, content, transactions — is stored here. Different filing systems work for different types of data. The biggest decision is whether all customers share one filing cabinet (cheaper, simpler) or each gets their own (more secure, more expensive).
For developers: Use PostgreSQL. It handles 95% of SaaS data needs beautifully — relational data, JSON columns, full-text search, and even time-series with TimescaleDB extension. Add Redis for caching and sessions. That's your data layer for the first $10M ARR. Add specialized databases only when you have a proven need.
5. Auth / Identity (Who Are You? What Can You Do?)
Authentication (who are you?) and authorization (what are you allowed to do?) are foundational to every SaaS product.
AUTHENTICATION FLOW
===================
User Frontend Auth Service Database
│ │ │ │
│ Login (email/pass) │ │ │
│ ──────────────────────▶│ │ │
│ │ POST /auth/login │ │
│ │ ────────────────────▶│ │
│ │ │ Verify creds │
│ │ │ ──────────────────▶│
│ │ │ ◀─── User record │
│ │ │ │
│ │ │ Generate JWT │
│ │ { token: "eyJ..." } │ │
│ │ ◀────────────────────│ │
│ Logged in! │ │ │
│ ◀─────────────────────│ │ │
│ │ │ │
│ GET /api/data │ │ │
│ Authorization: Bearer │ │ │
│ ──────────────────────▶│ Verify token ──────▶│ │
│ │ ◀── Valid, role=admin│ │
│ { data: [...] } │ │ │
│ ◀─────────────────────│ │ │What enterprise customers expect:
| Feature | SMB | Mid-Market | Enterprise |
|---|---|---|---|
| Authentication | Email/password | + Google/MS SSO | + SAML/OIDC SSO |
| MFA | Optional | Available | Required |
| Role management | Basic (admin/user) | Custom roles | Granular RBAC/ABAC |
| User provisioning | Manual | CSV import | SCIM auto-provision |
| Audit logging | None | Basic | Detailed, exportable |
| Session management | Simple | Timeout policies | IP restrictions |
Build vs buy: For auth, almost always buy or use a service (Auth0, Clerk, Supabase Auth, Firebase Auth, AWS Cognito). Rolling your own auth is a security risk and a distraction from your core product.
6. Billing / Payments (How You Make Money)
Billing is where your business model meets code. It's more complex than most founders expect.
BILLING SYSTEM COMPONENTS
=========================
┌─────────────────────────────────────────────────────────┐
│ BILLING ENGINE │
│ │
│ ┌─────────────┐ ┌──────────────┐ ┌───────────────┐ │
│ │ Plan / │ │ Usage │ │ Invoice │ │
│ │ Pricing │ │ Metering │ │ Generation │ │
│ │ Catalog │ │ │ │ │ │
│ │ - Tiers │ │ - API calls │ │ - Line items │ │
│ │ - Features │ │ - Storage │ │ - Taxes │ │
│ │ - Limits │ │ - Seats │ │ - Discounts │ │
│ │ - Prices │ │ - Events │ │ - Credits │ │
│ └──────┬──────┘ └──────┬───────┘ └──────┬────────┘ │
│ │ │ │ │
│ └────────────────┼─────────────────┘ │
│ ▼ │
│ ┌──────────────────┐ │
│ │ Subscription │ │
│ │ Management │ │
│ │ │ │
│ │ - Create/cancel │ │
│ │ - Upgrade/down │ │
│ │ - Trial mgmt │ │
│ │ - Proration │ │
│ └────────┬─────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────┐ │
│ │ Payment │ │
│ │ Processing │ │
│ │ (Stripe, etc.) │ │
│ │ │ │
│ │ - Charge cards │ │
│ │ - ACH/wire │ │
│ │ - Retry failed │ │
│ │ - Dunning mgmt │ │
│ └──────────────────┘ │
└─────────────────────────────────────────────────────────┘Billing is not just Stripe. Stripe handles payment processing. You still need:
- Plan/pricing catalog management
- Usage metering and aggregation
- Proration logic (upgrades and downgrades mid-cycle)
- Invoice generation
- Tax calculation (especially multi-state/country)
- Dunning (handling failed payments gracefully)
- Revenue recognition (important for accounting/audit)
Build vs buy: Use Stripe for payment processing. For billing logic, evaluate Stripe Billing, Orb, Lago, Metronome, or Chargebee depending on your pricing complexity. Build custom only if billing IS your product or your pricing model is truly novel.
7. Infrastructure (The Foundation)
Everything runs on infrastructure — servers, networks, storage, and the services that tie them together.
Major cloud providers:
| Provider | Strength | Best For |
|---|---|---|
| AWS | Broadest services, mature | Most SaaS companies |
| GCP | Data/ML, developer-friendly | AI-heavy products |
| Azure | Enterprise integration | Selling to Microsoft shops |
| Vercel | Frontend/full-stack deploy | Next.js-based products |
| Railway | Developer experience | Early-stage, fast shipping |
| Fly.io | Edge computing, global | Low-latency requirements |
Infrastructure costs typically follow this pattern:
INFRASTRUCTURE COST AS % OF REVENUE
====================================
50% │ ██
│ ██
40% │ ██
│ ██ ██
30% │ ██ ██
│ ██ ██
20% │ ██ ██ ██
│ ██ ██ ██ ██
10% │ ██ ██ ██ ██ ██
│ ██ ██ ██ ██ ██ ██
0% └─────────────────────
MVP PMF Growth Scale Maturity
Target: Get below 20% by Growth stage
Best-in-class: 5-10% at Scale8. Monitoring / Observability (The Nervous System)
You can't fix what you can't see. Observability is the practice of understanding what's happening inside your system.
The three pillars of observability:
┌───────────────────────────────────────────────────────────┐
│ THREE PILLARS OF OBSERVABILITY │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ METRICS │ │ LOGS │ │ TRACES │ │
│ │ │ │ │ │ │ │
│ │ Numbers │ │ Text events │ │ Request │ │
│ │ over time │ │ with context│ │ journeys │ │
│ │ │ │ │ │ across │ │
│ │ - CPU usage │ │ - Errors │ │ services │ │
│ │ - Latency │ │ - Warnings │ │ │ │
│ │ - Error rate│ │ - Audit │ │ - Latency │ │
│ │ - Req/sec │ │ trail │ │ per hop │ │
│ │ │ │ │ │ - Bottleneck│ │
│ │ Datadog, │ │ ELK, │ │ Jaeger, │ │
│ │ Prometheus, │ │ Papertrail, │ │ Honeycomb, │ │
│ │ Grafana │ │ Datadog │ │ Datadog │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ + ALERTING (PagerDuty, OpsGenie) │
│ + UPTIME MONITORING (Pingdom, Better Uptime) │
│ + ERROR TRACKING (Sentry, Bugsnag) │
│ + PRODUCT ANALYTICS (Amplitude, PostHog, Mixpanel) │
└───────────────────────────────────────────────────────────┘For non-technical readers: Monitoring is like the vital signs monitor in a hospital. It constantly checks heart rate (server CPU), blood pressure (memory), and temperature (error rates). If something goes wrong, it sounds an alarm (alert) so the doctors (engineers) can respond before the patient (your product) crashes.
For developers: At MVP, start with the basics — Sentry for errors, a simple uptime check, and structured logging. Add Datadog or Grafana as you enter Growth. Don't build custom dashboards until you have a team to look at them. The most important thing: set up on-call rotation and incident response before your first outage, not after.
How a Request Flows Through the Entire Stack
Let's trace what happens when a user creates a task in a project management SaaS:
1. User clicks "Create Task" in browser
│
2. Frontend sends POST /api/v1/tasks to API Gateway
│
3. API Gateway checks auth token (Auth Service)
│ ── Token valid? Yes. Role = "editor". Allowed.
│
4. Request routed to Task Service (Backend)
│
5. Task Service validates input data
│ ── Title present? Yes. Project exists? Yes. User has access? Yes.
│
6. Task Service writes to PostgreSQL (Database)
│ ── INSERT INTO tasks (title, project_id, ...) VALUES (...)
│
7. Task Service publishes event to message queue
│ ── "task.created" event with task ID
│
8. Notification Service picks up event (async)
│ ── Sends email/push to project members
│
9. Billing Service picks up event (async)
│ ── Increments usage counter (if usage-based pricing)
│
10. Search Service picks up event (async)
│ ── Indexes task for full-text search
│
11. API returns success to Frontend
│
12. Frontend updates UI optimistically
│
13. Monitoring logs the request (latency, status)
│
TOTAL TIME: ~200ms (user perceives ~50ms with optimistic UI)In Practice
What to Build When (Mapped to Lifecycle)
| Component | MVP | PMF | Growth | Scale |
|---|---|---|---|---|
| Frontend | One framework, minimal | Component library | Design system | Micro-frontends |
| API | REST, no versioning | REST v1, basic docs | OpenAPI spec, SDK | GraphQL, public API |
| Backend | Monolith | Modular monolith | Extract 1-2 services | Microservices where needed |
| Database | Single Postgres | + Redis cache | Read replicas | Sharding, multi-region |
| Auth | Email/pass (use Clerk) | + Google SSO | + SAML SSO | + SCIM, audit logs |
| Billing | Stripe Checkout | Stripe Billing | + Usage metering | Custom billing engine |
| Infrastructure | Railway / Vercel | AWS / GCP basics | IaC (Terraform) | Multi-region, K8s |
| Monitoring | Sentry + uptime check | + Structured logging | Datadog / Grafana | Full observability stack |
Common Architectural Mistakes
Microservices at MVP. You have 2 developers and 50 users. You don't need Kubernetes and 12 services. Start with a monolith and extract later.
No multi-tenancy plan. Retrofitting tenant isolation is extremely painful. Add a
tenant_idto every table from day one, even if you only have one customer.DIY auth. Every year, companies get breached because of homegrown auth. Use a battle-tested service.
Ignoring billing complexity. "We'll just use Stripe" works until you need proration, usage-based pricing, invoicing, tax compliance, and dunning. Plan for billing complexity early.
No data backup strategy. Test your backups by actually restoring from them. An untested backup is not a backup.
Premature optimization. Don't add caching, CDN, read replicas, or search engines until you have measurable performance problems. Premature optimization wastes weeks of engineering time.
Key Takeaways
- A SaaS product has eight major layers: Frontend, API, Backend, Database, Auth, Billing, Infrastructure, and Monitoring.
- Each layer has build-vs-buy decisions. Auth and billing should almost always be outsourced early on.
- Architecture should evolve with your lifecycle stage: monolith at MVP, modular monolith at PMF, selective microservices at scale.
- Multi-tenancy strategy (shared vs isolated databases) depends on your customer type and compliance needs.
- Start simple with managed services. Complexity is the enemy of shipping, especially pre-PMF.
- Observability (metrics, logs, traces) is not optional — invest in it from day one, scaling up the sophistication over time.
- The full stack works as a cohesive system. Understanding how a request flows end-to-end helps every role make better decisions.
Action Items
┌─────────────────────────────────────────────────────────────────┐
│ ROLE-BASED ACTION ITEMS │
├──────────┬──────────────────────────────────────────────────────┤
│ 🏢 Owner │ ☐ Understand your cloud cost structure and targets │
│ │ ☐ Decide build-vs-buy for auth, billing, infra │
│ │ ☐ Ensure data backup and disaster recovery plan │
│ │ exists │
│ │ ☐ Budget for observability tools from the start │
├──────────┼──────────────────────────────────────────────────────┤
│ 💻 Dev │ ☐ Choose your stack (see table above by stage) │
│ │ ☐ Add tenant_id to every table from day one │
│ │ ☐ Set up CI/CD pipeline before writing features │
│ │ ☐ Implement error tracking (Sentry) immediately │
│ │ ☐ Use a managed auth service (don't DIY) │
│ │ ☐ Document API contracts from the first endpoint │
├──────────┼──────────────────────────────────────────────────────┤
│ 📋 PM │ ☐ Learn what each layer does at a conceptual level │
│ │ ☐ Understand which features require which layers │
│ │ (e.g., SSO = Auth layer, export = Object Storage) │
│ │ ☐ Factor infrastructure constraints into roadmap │
│ │ ☐ Track uptime and performance as product metrics │
├──────────┼──────────────────────────────────────────────────────┤
│ 🎨 Design│ ☐ Understand loading states, errors, and offline │
│ │ behavior implications of the API layer │
│ │ ☐ Design for optimistic UI (instant feedback) │
│ │ ☐ Account for auth flows: login, signup, SSO, │
│ │ password reset, MFA │
│ │ ☐ Collaborate with devs on feasible real-time UX │
└──────────┴──────────────────────────────────────────────────────┘Previous: Chapter 3: SaaS Lifecycle | Next: Strategy Section — Coming Up