Tenant boundary
Tenant ids on every table, an application role with no bypass privilege, policies forced on so ownership is no escape hatch, and tests that attempt cross-tenant reads.
Isolation test suiteSoftware
Multi-tenant, metered, and ready to sell
We build the SaaS layer that makes software sellable repeatedly: a tenant boundary the database enforces, entitlements the app reads on every request, and the identity and audit surfaces enterprise buyers check.
- Fixed scope
- 14-day first demo
- Full IP transfer
- 30-day warranty
The work behind the subscription
Most SaaS projects are not hard because the features are hard. They are hard because everything has to be true for every tenant at once. One customer’s report cannot touch another customer’s rows, one customer’s bulk import cannot starve the queue, and the plan somebody bought in March has to still be the plan the code enforces in November. Features are the easy half; the invariants underneath them are what takes the time.
So we put the tenant boundary where a tired developer cannot forget it. Rows carry a tenant id, policies are forced on at the table so even the owning role obeys them, and tenant context is set per transaction rather than per session, because a pooler hands the same session to the next request. Billing is the other half: entitlements live in your database, driven by webhooks, so a provider outage degrades checkout rather than locking every customer out.
| What is true of this work | What it forces | What we do about it |
|---|---|---|
| One codebase serves every tenant | isolation cannot rely on discipline | forced row-level policies, cross-tenant tests |
| Connection poolers reuse database sessions | tenant context cannot live in the session | set per transaction, verified in tests |
| Plans change; signed contracts persist | entitlements must be versioned state | plan catalogue inside your database |
| Payment providers have outages | the request path cannot depend on them | webhooks sync, application reads locally |
| Inference cost scales with usage | flat per-seat pricing can invert margin | compute and model spend tagged per tenant |
In scope
- Multi-tenant schema with forced row-level security
- Billing, entitlements and metered usage
- Workspaces, roles, SSO and SCIM
- Admin console, audit log, per-tenant limits
Not in scope
- Migrating existing single-tenant installs onto it
- On-call and change work after warranty
- Price points, positioning and go-to-market
Handled by
- Software MigrationMoves live single-tenant installs onto the new platform.
- Maintenance & SupportTakes on-call, alerts and change work after handover.
What we build
Plans, entitlements, invoices
A plan catalogue you can change without a deploy, entitlements the app checks in-process, proration that reconciles, idempotent webhook handling, and dunning that recovers failed cards instead of silently churning accounts.
Entitlement serviceUsage metering
An event pipeline that counts what customers consume, aggregates it per tenant per period, shows the same number in the product and on the invoice, and can shadow-run new pricing.
Metered usage pipelineWorkspaces and identity
Signup, workspaces, invites, domain-claimed joins, and roles that mean something before single sign-on arrives, then per-tenant SAML or OIDC connections and SCIM provisioning in the order buyers ask for them.
SSO and SCIM provisioningBack-office console
The tool support lives in: tenant search, plan overrides, credits, feature flags, and impersonation that writes an audit entry naming the staff member, not the customer they were acting as.
Audited admin consoleBlast-radius limits
Per-tenant rate limits, queue quotas, and job fairness so one customer’s overnight import does not become everybody’s incident, plus cost tags attributing compute, storage, and inference spend back to the tenant.
Per-tenant quota policyHow the work runs
- 01Week 1
Tenancy and pricing
We settle two things before any feature work: where the tenant boundary sits, and how money is counted. Pooled or isolated, per seat or per unit, who can invite whom. Both decisions leak into every table.
You getTenancy and pricing decision record
- 02Weeks 2–3
Tenant skeleton
We build the boring spine end to end: signup, tenant provisioning, first login, invite a colleague, switch workspace, and an isolation test that tries to read another tenant’s rows and fails.
You getRunning signup-to-workspace demo
- 03Weeks 4–10
Workflow and billing
Now the thing customers buy: the workflow that justifies a recurring invoice, with tenant context threaded through the API, jobs, and exports. Then plans, checkout, proration, and the entitlement checks the product reads before acting.
You getPaid workflow with billing in test mode
- 04Weeks 11–16
Sellable and supportable
Roles, audit log, admin console, per-tenant limits, backups you have restored at least once, and the runbooks your team needs at 2am. Infrastructure as code lands in your own cloud accounts.
You getProduction tenant on your accounts
What you are handed
- Multi-tenant Postgres schema with forced RLS
- Cross-tenant isolation test suite
- Plan catalogue and entitlement service
- Metered usage pipeline with shadow billing
- Per-tenant SSO and SCIM provisioning
- Admin console with audited impersonation
- Automated tenant provisioning and offboarding jobs
- Per-tenant quota policy and cost dashboard
- Runbooks for dunning, incidents and restores
Typical stack
Tenancy & data
PostgreSQLRow-level security policiesPgBouncerRedisS3-compatible storage
Application
Django + DRFCeleryTypeScriptReact and Next.jsOpenAPI contracts
Money & identity
Stripe BillingEntitlement storeSAML and OIDCSCIM 2.0Keycloak or WorkOS
Operations
DockerTerraformGitLab CIOpenTelemetrySentryPlaywright and k6
The calls we make, and why
Should every tenant share one database, or should each get their own?
Share one database, with forced row-level security.
Pooled tables scale to thousands of tenants on one migration, one connection pool, one backup. Schema-per-tenant sounds safer and becomes a deploy that touches five thousand schemas and drifts. We build routing indirection on day one, so a single tenant can be lifted out without a rewrite.
We’d choose otherwise whena signed contract or a residency rule requires a tenant’s data physically apart.
Do we let the billing provider be the source of truth for what a customer can do?
No. The provider owns money; your database owns entitlements.
The provider handles cards, invoices, tax, and dunning. Your database holds the row the request path reads to decide whether this tenant may export, invite, or call the API again. Webhooks keep the two in sync, with idempotency and a reconciliation job.
We’d choose otherwise whenthe product is pure self-serve with three static plans and no enterprise contracts.
Per seat or usage-based pricing?
Sell seats first, but meter consumption from day one.
Seats are easy to forecast and easy to buy, and they let you launch while you learn what a heavy customer looks like. Instrument consumption immediately anyway, because retrofitting a meter into a year-old codebase is a rewrite, and shadow-bill before switching anyone.
We’d choose otherwise whenthe product’s own cost genuinely tracks usage, as with anything inference-heavy, and buyers expect metering.
Should we build our own authentication so we are not locked in?
Buy identity; keep the user table in your database.
Single sign-on is not a login form. It is per-tenant SAML and OIDC connections, certificate rotation, SCIM lifecycle, and a support queue full of somebody else’s identity provider. A hosted provider is worth its bill for years of that work.
We’d choose otherwise whenyou already run an identity provider in-house, or your tenancy model breaks every vendor’s workspace assumption.
This fits if
- You sell a repeatable service and want to productise it
- Design partners are signed and need a product before renewal
- Your single-tenant installs each run a slightly different branch
- An enterprise buyer wants SSO, audit logs, isolation proof
- You are guessing at pricing because nothing measures consumption
Look elsewhere if
- You need one system for one organisation, not a product
- No paying design partner yet and the problem is a hunch
- Thousands of live tenants need re-platforming without downtime
EngagementFixed-scope build
Typical length10–16 weeks
How it startsSend us your pricing page draft, or the spreadsheet your customers currently live in.
Questions we get asked
How quickly can we put this in front of a paying customer?
You see a working multi-tenant demo within 14 days of kickoff, and a first sellable release typically lands between ten and sixteen weeks. The variable is not engineering speed; it is how long pricing and permissions take to settle. Teams arriving with a decided plan structure and a named first customer ship sooner.
Who owns the code, and what happens if we part ways?
You own all of it. The IP assignment is in the contract you sign at the start, not a handover performed at the end, and the repository, infrastructure definitions, billing configuration and cloud accounts sit in your organisation from the first week. No runtime licence, no hosted component we keep, nothing held back.
What will it cost to run each month once we have customers?
Under a hundred tenants on pooled infrastructure, hosting is the smallest line: database, cache, object storage, a queue. The costs that surprise people are the percentage a billing provider takes on usage-based plans, the per-connection price of enterprise identity, and inference if the product has AI features. We show those as cost per tenant before you set prices.
Do we need SOC 2 before we can sell to enterprises?
Usually not for your first enterprise deal: a completed security questionnaire and a dated audit plan clear most procurement. Regulated buyers and large procurement teams do hard-gate on the report itself. Build the evidence either way: an append-only audit log, roles rather than an admin flag, access reviews you can run, and encrypted backups you have restored.
What happens if something breaks after launch?
Every build carries a 30-day warranty from handover: defects in what we shipped are fixed by us, at no charge, on the same priority we would give our own production. You also get the runbooks, alert thresholds and restore procedure your team needs for everything else. Beyond the warranty, on-call and change work move to a support retainer.
Often bought alongside
Tell us the requirement.
Thirty minutes with the engineers who would build it. You leave with a scope, a timeline and a fixed price — or an honest no, and the reason why.