🏗️ Multi-Tenant SaaS Architecture Starter Kit

An opinionated Rails + PostgreSQL starter kit that bakes in proper tenant isolation, subscription billing, and a permission model from day one — so founders don't architect themselves into a corner.

Most SaaS applications start as single-tenant monoliths and only try to add multi-tenancy after they have paying customers, a growing team, and a lot of existing assumptions baked into the schema. By then it's painful. The idea is a starter kit that makes multi-tenancy a first-class concern from the first commit.

The core of the kit would be a Rails application using row-level tenant isolation via a tenant_id scope on every model, enforced at the application layer with a global before_action that sets the current tenant from the subdomain or JWT claim. PostgreSQL row-level security would add a second enforcement layer for defense in depth. The kit would ship with a Stripe billing integration that maps tenants to subscriptions and gates feature access through a simple capability model rather than hardcoded plan checks.

Permission modeling is where most teams make expensive early mistakes. This starter kit would include a role-permission system where roles are scoped to a tenant, and permissions are expressed as policy objects rather than scattered conditionals. The goal is that when requirements grow — a customer wants an "admin" role with custom capabilities — the model bends without breaking.

The real value proposition isn't the code; it's the documented architectural decisions that explain the tradeoffs and tell you where to change course if your use case diverges. Architectural literacy built into the template itself.