Multi-tenant CRM for a services group
One product, one deployment, a separate database per subsidiary.
The problem
A group of subsidiaries wanted a single CRM, but each entity needed a hard data boundary for compliance. Shared-table tenancy with a customer_id column was not going to survive an audit.
What I built
Database-per-tenant on a shared Laravel application, with tenant-aware migrations and queues. Mail synchronisation, document scanning with OCR, invoicing and signature flows all run as queued work under Horizon. Infrastructure lives on AWS EKS and deploys through ArgoCD, so a release is a commit rather than an evening on a single laptop.
Where it landed
Onboarding a new subsidiary is a migration run against a new database, not a deployment. One codebase, one upgrade path, and a data boundary that is a boundary rather than a WHERE clause.