Multi-tenant architecture
Patterns for multi-tenant SaaS systems without sacrificing isolation or speed.

Multi-tenancy enables scale without reinventing the wheel for each client. The key is enforcing isolation by design — not as an afterthought — while keeping customization flexible enough to make each tenant feel unique. This article covers patterns I've applied in production at GetGround and Richemont.
Key takeaways
- Isolation must be a system property (operatorId on every entity), not a runtime check
- Customization levers (branding, feature toggles) make shared platforms feel tailored
- Automation scripts for client provisioning accelerate onboarding from weeks to days
Notes on Multi-Tenant Architectures in Practice
When I look back at projects like GetGround and my mission at Richemont, multi-tenant architecture was not an afterthought — it was a requirement from day one. Both products were designed as greenfield builds, and the core driver was white-labeling: enabling multiple enterprise clients (or, in Richemont's case, multiple luxury brands) to use the same platform while keeping branding, features, and data strictly isolated.
Why Multi-Tenant?
The business needs differed slightly but pointed to the same solution:
- GetGround needed a platform that could be white-labeled for multiple clients — each with their own colors, logos, and feature set.
- Richemont, as a luxury group, owns multiple "maisons" (brands). Each maison needed its own flavor of the application, but it made no sense to rebuild the entire stack per brand.
Multi-tenancy gave both organizations the ability to scale, while keeping operations lean.
Architectural Choices
- GetGround: We implemented a shared database with operator isolation on AWS DynamoDB. Every entity carried an operatorId, ensuring strict separation between clients while keeping the operational model lightweight and cost-effective.
- Richemont: The group relied heavily on Salesforce as a backbone. Multi-tenancy here supported multiple maisons under the same umbrella, while ensuring each brand had its own identity within a common system.
Ensuring Isolation
Isolation was enforced by design:
- Every record in DynamoDB carried an operatorId.
- APIs and services required the operator context to function.
- Access controls respected operator boundaries at all levels of the stack.
This made data segregation a property of the system itself, not an afterthought.
Customization Levers
Multi-tenancy only works if each tenant can still feel unique. We enabled that at two levels:
- Branding: colors, logos, and images were tenant-specific and could be applied dynamically.
- Features: clients could request features to be enabled or disabled.
- For mobile apps, toggles were applied via Firebase Remote Config.
- For web apps, toggles were managed from the Back-Office.
- Importantly, clients couldn't just flip features themselves. Some features came with additional costs, so enabling them required a request and approval process.
Challenges Along the Way
One of the hardest parts was migrations.
Because tenants shared the same codebase and infrastructure, a major migration required updating every client's apps. We invested in automation, but version alignment remained a coordination challenge.
Another recurring friction was infrastructure provisioning. We had scripts that could create a new client's base environment in about a minute. But they weren't fully optimized — some manual steps remained, and with more time, those scripts could have become a true one-click onboarding pipeline.
The Payoff
The benefits were clear:
- Faster onboarding: A complete client setup — infrastructure, back-office, mobile app, and web app — could be deployed in about a week.
- Lower costs: Shared infra and codebase reduced maintenance overhead.
- Flexibility: Clients received tailored apps without us needing to reinvent the wheel each time.
Reflections
The system proved solid. Simplicity was a guiding principle, which made it reliable in production. If I had to improve it, I'd revisit the automation scripts: making them more comprehensive and modular would reduce human intervention and accelerate onboarding even further.
Tech at a Glance
- AWS DynamoDB with operatorId-based isolation
- Firebase Remote Config for mobile feature toggles
- Custom Back-Office (React + NestJS) for web feature toggles
- Salesforce (Richemont) for maison-level multi-tenancy
- Infrastructure scripts for rapid client provisioning