Tenant-First Thinking: The Question We Ask Before Every Feature

VoVo, our website and business platform, serves many organizations from one installation. A church, a coaching practice and a small shop may all be using the same servers and the same database at the same moment. That design keeps the platform affordable and easy to improve, but it puts one responsibility above all others: each customer's data must stay theirs.

We call our approach tenant-first thinking. In our vocabulary, a "tenant" is one customer account, and the question we ask before writing any feature is simple: whose data is this, and does every part of the code know it?

Why the question has to come first

In a single-customer application, a bug usually means something breaks. In a multi-tenant platform, a bug can mean one customer sees another customer's members, orders or messages. That is not an inconvenience. It is a breach of trust.

Most of those bugs are not dramatic. They come from small assumptions: a cache key that forgot to include the customer, a search box that looked through every account, a background job that ran without knowing which customer it belonged to. Tenant-first thinking is the habit of catching those assumptions before they ship.

The checklist we run through

Every feature is checked against the same short list.

1. Does the code ask "which customer?" safely?

Some of our pages run inside a customer account and some run on our public marketing site, where there is no customer at all. Code that assumes a customer exists will crash on the marketing site. So we always check safely whether a customer context is active before using it, and we write code that works in both places.

2. Does every cache key include the customer?

A cache stores answers so they do not need to be computed again. If two customers' answers share the same cache key, one customer can be shown the other's data. Every key we create includes the customer's identifier, and often the specific website within that account.

3. Is every database query scoped?

Most of our data models apply an automatic filter so queries only see the current customer's rows. We rely on it, but we do not trust it blindly. Background jobs, command-line tools and data seeders may not have that filter active, so those paths filter explicitly.

4. Are files stored in the customer's own space?

Uploaded images, documents and exports live under paths that belong to one customer. The media library records which account and which website each file belongs to.

5. Do sessions and background jobs carry the customer with them?

When work moves to the background, such as sending email or processing an image, the job records which customer it belongs to and restores that context before it runs. A job that forgets is a job that can write into the wrong account.

The special case of people

User accounts are a little different in our platform. One person can belong to more than one customer account, so a user record does not belong to a single customer. That means a careless dropdown that lists "all users" would list people from every account. We never do that. Lists of people are always built from the membership records of the current account. You can read more about that pattern in why we never load every user into a dropdown.

How the checklist shows up in daily work

The checklist is written into our engineering standards and into the instructions our AI coding assistants follow. Reviews look for it specifically. When we find a gap, we fix it at the shared level when possible, so the whole platform benefits.

Tenant isolation is not a feature customers see. It is the reason they can trust everything else. If you are evaluating a platform for your organization, ask how it keeps accounts apart. And if you want to see what we have built on these principles, explore VoVo.

Frequently asked questions

What is a tenant in software?

A tenant is one customer account in a platform that serves many customers from the same system. Each tenant's data, settings and files must stay separate from every other tenant.

Is a shared database safe for many customers?

It can be, when every query, cache, file path and background job is scoped to the right customer and that scoping is reviewed carefully. Separate databases are another option, with different trade-offs in cost and maintenance.

Why not rely only on automatic query filters?

Automatic filters are a strong default, but they may not be active in background jobs, command-line tools or data scripts. Explicit filtering in those paths closes the gap.