Multi-Tenant SaaS Platform

The problem

The company needed a SaaS platform built from scratch capable of serving multiple clients (“tenants”) with fully isolated configurations, brands, and data. Existing market options were either too generic or too expensive for the target segment. The decision: build.

The technical challenge wasn’t just “build a SaaS” — it was building it correctly from the first commit, with enough structure that customer number 100 wouldn’t require rewriting what worked for the first one.

Architectural decisions

Multi-tenancy with database-per-tenant isolation. Each tenant gets its own database. More operational complexity, but guarantees real isolation, simplifies the per-tenant data model, and keeps open the option of hosting growing tenants on dedicated infrastructure.

Custom domains per client. The system supports both subdomains (client.app.com) and full domains (app.client.com) per tenant, with automatic certificate renewal. Lets each client operate under their own brand with no friction.

Centralized admin panel. Filament (Laravel) over the master database for internal operations: tenant provisioning, metrics, support. Separate from the end-user product to keep responsibilities and schemas clean.

Modular monolithic stack. Laravel + Inertia + Vue 3 — a single deployable, but with well-separated modules. Resist the temptation of premature microservices: they are introduced only when the monolith starts to hurt, not before.

AWS infrastructure with Docker and traceable CI/CD. Every release has a commit, a build, a recorded deploy, and a rollback path. No surprises in production.

Building

Development was structured under Spec-Driven Development: every major feature went through an approved spec before implementation. Specifically for tenant provisioning and domain routing — that’s where mistakes cost money.

Priorities:

• Per-tenant migrations that are automatable and reversible
• Observability: structured logs, business metrics, alerts that matter
• Backups and disaster recovery from day one, not as an afterthought
• New-developer onboarding: a real README, working make scripts, a local environment with docker compose up

Outcome

Platform operating stably in production, serving tenants. System ready to grow in customer count without a rewrite — the next scale level is operational (more tenants), not architectural (changing the stack).

The technical team stays small and productive thanks to the spec discipline and the observability in place. The technical decisions made in 2022 remain correct today.

What I learned

• Multi-tenancy with database-per-tenant is more work but less pain long-term. The alternatives (single DB with tenant_id) look simpler initially and become the central problem within two years.
• Filament accelerated the admin panel massively. A 3-month custom-admin job became 3 weeks with Filament plus targeted customization.
• Inertia is the sweet spot between pure SPA and traditional Laravel. Hot reload, SSR, no need to maintain a separate REST API for your own front.
• AWS isn’t necessarily the right answer — but when it is, Docker + properly done CI/CD make the complexity manageable.