Software Growth

Single-tenant (architecture)

Single-tenant means each customer gets their own dedicated instance of your software and often their own infrastructure, instead of sharing one stack.

In a single-tenant setup, every customer runs on a separate copy of the application, usually with its own database and often its own servers or cloud account. The opposite is multi-tenancy, where customers share one running system. Single-tenant is not the same as self-hosted: in the single-tenant case you still operate the software, you just run a private copy per customer.

Why customers ask for it

EnterpriseReady, a guide to features large buyers expect, notes that organizations in finance, legal, healthcare and government demand flexible deployment models, from single-tenant hosted instances to on-premise installs, driven by security, compliance and integration with internal systems. In practice the request sounds like:

  • "Our data cannot sit next to other companies' data."
  • "We need it in a specific region or our own cloud account."
  • "We want to control when upgrades happen."
  • "Our security team will not approve shared infrastructure."

Sometimes the real need is satisfied by good tenant isolation, encryption and a clean SOC 2 report. Ask what the risk is before agreeing to dedicated infrastructure.

Single-tenant vs multi-tenant

  • Isolation. Single-tenant is stronger by default. A bug or noisy neighbor in one customer's stack cannot touch another.
  • Customization. You can set versions, regions, retention and integrations per customer.
  • Cost. Each instance has a floor cost even if the customer barely uses it. Your gross margin drops unless price reflects it.
  • Operations. You now run N deployments. Upgrades, migrations, monitoring and incident response multiply.
  • Speed of shipping. If customers sit on different versions, support has to know which one each is on.

How to sell it without losing money

The clean approach is to treat it as a premium tier. Charge for the dedicated instance explicitly, require an annual contract, and set a minimum that covers the infrastructure and the engineering time to maintain it. Rob Walling's advice on enterprise deals, as discussed on Startups for the Rest of Us, is to charge for custom work on top of the monthly fee with minimum annual commitments, and to charge more than you think you should. That fits here.

A worked check: a dedicated stack costs you $900 a month in cloud bills and about 6 engineering hours a month at an internal cost of $100 an hour, so $1,500 a month. A $1,000 a month contract loses money before support. At $4,000 a month you keep a healthy margin.

Keep it manageable

  • Use the same codebase and release for every instance. Do not fork per customer.
  • Automate provisioning with infrastructure as code so a new instance takes an hour, not a week.
  • Use feature flags for per-customer differences instead of branches.
  • Make SSO and audit logging work the same on every instance.

When a small SaaS should care

Not before a deal demands it. Start multi-tenant, and when the first serious buyer asks for dedicated hosting, price it as a separate plan and build the automation only if two or three similar requests follow. Most small teams are better off saying "we offer logical isolation, encryption and a SOC 2 report" and keeping one stack.

Related terms

Sources

Back to the SaaS glossary