OrderBind Multi-Tenant SaaS.

A multi-tenant order platform with RLS-enforced isolation, role-based admin, audit logging, and credit-based usage metering. Across 50+ migrations.

Built at: TechnicalBind
Scale: Multi-tenant SaaS with super admin / admin / member roles, credit-metered usage, and audit logs across 50+ schema migrations.
Category: SaaS

Migrations: 50+
RLS Coverage: 100%

Context

Small operations teams were running orders, customers, and procurement across separate tools, and could not justify enterprise ERP pricing.

Challenge

Build tenant isolation strong enough to withstand a hostile tenant, without a service-per-tenant deployment pipeline.

Non-negotiables

Tenant data must never leak, even on application bugs
Credit metering accurate to the action
Audit logs that survive admin actions

Calls I made

01
RLS, not application checks
Every table carries a row-level security policy keyed on tenant id. Application code that forgets the filter still cannot leak data.
02
Credits as RPCs
Metered actions go through Supabase RPCs that check and decrement credits in the same transaction. No race window.

Trade-offs accepted

50+ migrations and counting. Chose forward-only over rebasing history. Slower to read, but every production schema state is reproducible.
Deferred per-tenant subdomains in v1. Path-based routing was enough to ship.

Outcome

Tenants are isolated at the database layer, billing matches usage at the action level, and audit logs persist across admin operations.

In multi-tenant SaaS, the database is the right place to enforce isolation. Application-layer checks are useful, but they are not the boundary.
What I took away

Stack