SaaS
one platform,every tenant
Multi-tenant products where each customer gets their own brand, data, and plan, and the team still ships one codebase. Billing, analytics, and releases included.
Illustration: an admin view of four sample workspaces, each isolated with its own tenant id, plan, and seat usage, with a feed of upgrades, seat invites, and invoices.
- white-label tenants on one platform
- 5
- average response time
- −40%
- deployment time
- −70%
- uptime on the AWS stacks I run
- 99.95%
01 · The hard part
Where SaaS products stall
The first ten customers are a product problem. The next hundred are a platform problem.
A fork for every big customer
Custom branding and settings end up as copies of the codebase, and every fix has to land five times.
Billing drifts from the plan
Seats, upgrades, and invoices live in different places, so the plan a customer has and the plan they pay for disagree.
Dashboards slow down as data grows
Analytics runs against the product database until the reports and the app start waiting on each other.
Releases the team is afraid of
Manual deploys mean fewer releases, bigger batches, and more of them rolled back.
02 · What I build
Four parts of a SaaS platform
Pick a tab. Each one is work that has run in production, tied to where it ran.
White-label and multi-tenant
One engine, many branded tenants. Configuration decides the brand, the domain, and the features, not a fork.
- Per-tenant branding and domains
- Shared reservation and payments engine
- Tenant-scoped data access
- Feature flags per tenant
- One codebase, one release
- Operator back office
03 · Stack
The tools behind the work
The stack behind the tenants, the bills, and the dashboards.
Front end
- React
- Next.js
- Angular
- TanStack Query
- TanStack Router
API & data
- NestJS
- GraphQL
- Node.js
- PostgreSQL
- BigQuery
Billing & identity
- Stripe
- Stripe Connect
- Cognito
- JWT
Platform
- AWS
- GitHub Actions
- CloudWatch
- Looker
04 · Platform hygiene
Tenants stay separate, releases stay boring
The controls that let one codebase serve many customers without one customer seeing another.
Tenant scope on every query
Data access is scoped by tenant at the API layer, so a missing filter is a failing test, not a leak.
One identity provider
Sign-in, MFA, and revocation live in one place instead of per-tenant user tables.
Secrets out of the repo
Keys live in the cloud's secret store, scoped per environment.
Least privilege per service
Each service gets the permissions it needs and nothing else, with changes logged.
CI gates before release
Tests, types, and lint run on every push; production deploys only from a passing build.
Monitoring and alerting
Dashboards and alerts are part of the first deploy, not a ticket after the first outage.
These are engineering practices, not certifications. SOC 2 reports come from your auditor; the platform is built so the evidence is already there.
Building the platform, not just the product?
Tell me how many customers you have now and how many you expect. I will come back with where the platform bends first and what I would build before it does.