Tenant-per-Site vs Tenant-per-Company: The ERPNext SaaS Architecture Decision
ERPNext Doctrine: The foundation you choose becomes your advantage — or your prison.
Every ERPNext-powered startup makes a foundational decision — often silently — that determines whether it will scale cleanly…
or spend years fighting its own system.
That decision is simple:
Will each customer be its own ERPNext site — or will all customers live inside one giant site?
Most founders make this choice without understanding what they are truly choosing.
They pay for it later.
The Two ERPNext SaaS Architectures
When you build SaaS on ERPNext, you are choosing between two fundamentally different operating models.
1) Tenant-per-Site
Each customer receives an isolated ERPNext site:
- Independent database
- Independent users and permissions
- Independent accounting
- Independent backups
- Independent compliance boundary
Your SaaS platform becomes a site factory — a real multi-tenant cloud.
2) Tenant-per-Company
All customers are placed inside one massive ERPNext site, separated by companies, branches, cost centers and permissions.
It feels simpler at the beginning.
It feels cheaper.
It feels faster.
It is also the architecture that quietly destroys SaaS startups.
Why Tenant-per-Company Collapses at Scale
Tenant-per-company works — at first.
Then reality arrives:
- Backups cannot be restored per customer
- Custom logic becomes political and risky
- Performance tuning affects unrelated businesses
- Legal data separation becomes dangerous
- One client’s bug threatens everyone
- Migrations, exports and exits become nightmares
You built a shared nervous system for unrelated companies.
That is not SaaS.
That is technical debt with branding.
Why Tenant-per-Site Wins Long-Term
Tenant-per-site is heavier at the beginning.
But it gives you what SaaS ultimately requires:
- Customer-level backups
- Customer-level scaling
- Customer-level upgrades
- Customer-level compliance
- Customer-level custom logic
- Clean legal separation
- Clear exit paths
It turns your SaaS into real infrastructure — not a shared experiment.
The Quiet Superpower: Upgrade Independence
With tenant-per-site:
- You upgrade customers in controlled batches
- You isolate failures cleanly
- You roll back safely
- You test changes without harming production customers
This is how mature SaaS platforms survive.
Where Each Model Fits
Tenant-per-Company
Good for
- Internal group companies
- Parent + subsidiary setups
- Shared finance teams operating within one corporate structure
Dangerous for
- Public SaaS
- Unrelated businesses sharing one database
- Products that require strong customer isolation and clean exits
Tenant-per-Site
Good for
- Public SaaS platforms
- Compliance-heavy customers
- Products that need per-customer upgrades, backups, and migrations
Trade-off
- Higher infrastructure cost (but clean scaling and isolation)
This Is How Real African SaaS Is Being Built
This is not theory.
These platforms already run on tenant-per-site foundations:
- TrashIQ
- Wavu
- SaccoPlus
- DukaPlus
- upeoCRM
- AjiraQuest
They are not apps.
They are digital operating systems.
Choose Your Foundation Carefully
You can change features.
You can change UI.
You can change branding.
But you cannot easily change your tenant architecture.
That choice either becomes your greatest advantage —
or your permanent prison.