Single-tenant deployments promise control and deliver abandonment. A look at why one hardened codebase serves a small business better than a copy of its own.
The appeal of a private copy
Ask a mid-sized distributor whether they would like their own instance of a system and the answer is almost always yes. A private copy sounds like control: our data, our server, our rules. It is a reasonable instinct, and for a decade the industry sold into it.
What follows is less reasonable. A private copy is a private maintenance obligation. The vendor now has as many codebases as customers, each drifting from the others with every custom field and every urgent patch. Two years later a security fix takes a month to roll out because it has to be applied forty times, and the customer with the most customisation gets it last.
What multi-tenancy actually buys the customer
In a multi-tenant architecture every customer runs on the same code against a partitioned data layer. The benefits accrue to the customer more than to the vendor:
- A security patch reaches everyone in one deployment, not forty.
- Features built for one customer's problem are available to all of them, which is how a product gets good.
- Infrastructure is sized against aggregate load, so a small customer gets availability engineering they could never fund alone.
- The vendor's incentive shifts from billing for changes to making the default better.
The objections worth taking seriously
Data isolation
The legitimate concern is not whether isolation is possible but whether it is enforced consistently. In our own products the tenant boundary is applied at the query layer rather than left to each developer to remember, and access is tested as part of the build. Isolation you can demonstrate beats isolation you assert.
Customisation
Genuine process differences exist. The answer is configuration and extension points, not forks. Custom fields, configurable workflows, role-based permissions and a documented API cover the overwhelming majority of what customers actually ask for when the request is examined.
Compliance
GST, e-invoicing and record-retention requirements are the same for every Indian business of a given class. This is the strongest argument for a shared codebase: when the portal specification changes, every customer needs the same change, on the same date.
Where single-tenant still wins
There are cases. A regulated entity with a contractual data-residency requirement that the vendor cannot meet in a shared environment. An organisation whose volume genuinely justifies dedicated infrastructure. A deployment that must run disconnected from the internet. These are real, and they are rarer than the sales conversation suggests.
The practical test
Before accepting a private instance, ask the vendor three questions: how long does a security fix take to reach every customer; what happens to our customisations when the base product upgrades; and who applies the patch when your engineer who knows our instance leaves. The answers usually settle it.
Working on something this touches?
Start a conversation