Multi-tenant SaaS platforms, built to production
A prototype proves an idea. A platform survives its second customer, its first billing dispute, and the week a background job silently stops running. The distance between those two things is most of the work, and it is the part that gets underestimated.
Built and shipped, not prototyped — auth, billing, tenancy, queues and observability included.
Where it actually goes wrong
The decisions that decide whether a SaaS product can grow are made in the first month and are almost invisible: how a tenant is represented, whether identity is separable from the application, whether anything asynchronous can be observed after it fails.
Retrofitting tenancy or auth into a product that already has customers is not a refactor. It is a migration, with downtime and risk attached — which is why it is worth getting right before the first customer, not after the tenth.
What you get
- A tenancy model that holds
- Isolation decided deliberately rather than inherited from whatever the first customer needed.
- Auth and billing as infrastructure
- Identity and subscription state kept separable from product logic, so neither becomes the thing you cannot change.
- Queues and scheduled work
- Background execution with retries and an audit trail, because the jobs nobody watches are the ones that fail quietly.
- Observability from day one
- Instrumented before launch, not added during the first incident.
- Infrastructure that is not an afterthought
- Container delivery on Cloud Run with builds wired to GitHub, so a merge is a deploy. A load balancer with filtering and a CDN in front of object storage where traffic is public and media-heavy. The unglamorous half of shipping a platform, and the half that decides what a traffic spike costs you.
One lesson I paid for rather than read: on a rescue engagement I was asked to build domain modules first and wire authorization across them afterwards. It does not work. Authorization spans everything, so it constrains everything — designing it after the modules exist means redesigning the modules. Cross-cutting concerns come first, and I will say so early even when it slows the first demo down.
Where I have done this
- What's The Deal — co-founded and built. Three years live in market on iOS, Android and web, on a Kotlin and Ktor backend with MongoDB.
- Surefire Fundraising — built from nothing for an Edmonton client. The business did not exist before the platform did, and I still maintain it.
- As an employee: a client-facing investor platform for a private capital firm, launched with its first fifteen high-net-worth investors onboarded, leading a team of three.
- KeystoneOS — my own product, in private beta: multi-tenant, with Stripe, WorkOS, Twilio, Nylas, SendGrid and PostHog integrated on Postgres.
- Google Cloud across the recent work: Cloud Run and Cloud Build for delivery, Cloud Load Balancer with Cloud Armor and Cloud CDN in front of Cloud Storage for public traffic, Pub/Sub, Cloud Functions and Cloud Scheduler for asynchronous work, and Firebase where it fits.
- Multi-tenant architecture
- Kotlin · Ktor
- Laravel · PHP
- TypeScript · Next.js
- Stripe billing
- WorkOS auth
- Postgres · MongoDB
- Google Cloud — Cloud Run, Cloud Build, Cloud Functions, Cloud Scheduler
- Load balancing, Cloud Armor, CDN
- Queues and background execution
- Observability from day one
Describe it in a paragraph.
Tell me what the system is, what it is doing wrong, and what has to be true by when. I will tell you whether I am the right person for it — including when I am not.
The other three
- Integration & data migration
The promise is not that I will connect your systems. It is that your integration survives a replay, a spike, and an outage.
- AI systems that do real work
Sold on the auditing, cost control, idempotency and evaluation — the parts that decide whether it survives contact with production.
- Technical due diligence & rescue
A fixed-scope audit of a stalled or inherited system, delivered as a prioritized roadmap you can act on.