Perspective
Settle Tenancy, Separation and Roles First, Then Build the Features on Top
A subscription product's first decisions are made before its first feature: what a customer is, how data is kept apart and who may do what. We settle them early, while change is cheap.
5-minute read4 November 2026
In Brief
- A feature can be rewritten on its own. Tenancy reaches every table, query, file, cache, job and export, so changing it once customers are live means changing all of them at once.
- Four actions: define what a tenant is, choose how far apart the data must be, treat roles as a model of permissions and scopes, and prove it with a thin slice and two test tenants.
- Thinqmesh builds the accounts, teams, billing, permissions and admin tools around these decisions, and you own the code, the data and the accounts from the first day.
Founders and product leaders tend to plan a subscription product around its features, because features are what customers ask for and what investors can see. Three decisions come before any of them: what counts as a customer, how one customer's data is kept apart from another's, and who may do what once they are inside. They are often made by default, in the first week, by whoever writes the first table.
The First Decisions Are the Costliest to Change
A weak feature can be rewritten on its own. Tenancy runs through every table, query, file path, cache key, background job, log and export, so changing it after launch means changing all of those while customers are using them. Roles behave the same way: an early check that asks whether a user is an administrator gets copied into a hundred places.
We make these decisions with you before the first feature and keep what can wait out of the build: dedicated deployments, regional hosting and elaborate billing can follow. What cannot wait is small: a tenant identifier on every record, one place where permissions are checked, and the ability to export and delete a single tenant. Getting that foundation right early prevents an expensive rewrite when customers arrive.
Four Decisions to Settle Before the Second Feature
Each one fits on a page, and each protects every feature built after it.
Define What a Tenant Is
The question sounds trivial until the first real customer arrives.
A group with four subsidiaries may want separate data and a consolidated view. An accountant may need thirty client companies from one login. Decide whether a person can belong to several tenants, whether tenants can have parents and which level you bill. The answers may be simple, and they should be deliberate.
Get started
- Write one page that defines a tenant and the relationships between them.
- List the customer types you expect in the first year and test the definition against each.
Choose How Far Apart the Data Must Be
Most new products can begin with shared infrastructure and a way to move a demanding customer to dedicated resources later.
Separation should be enforced below the application, so that it does not depend on every developer remembering a filter, and it applies to files, caches, search indexes and logs as well as tables. We keep each customer's data separate from the first release and plan recovery for a single customer.
Get started
- Ask your intended customers early whether they need their own keys, backups or locations.
- List every place customer data lives apart from the main tables.
Treat Roles as a Model
Permissions, roles and scopes are three different things.
A permission is one action, a role is a named bundle of permissions and a scope is where the role applies. Checks in the code ask about permissions and never about role names, so a manager who can approve but not export is a configuration change. Settle early how your own support staff reach customer data, with an audit record.
Get started
- List the first permissions, roles and scopes on one page.
- Decide what happens when a tenant's last administrator leaves.
Prove It With a Thin Slice and Two Test Tenants
One record type, one file, one background job and one export.
Build the slice under the rules you have written, then act as one tenant and try to reach the other's data through each of them. Confirm you can export and delete a single tenant. A team that cannot do that does not fully know where a customer's data is.
Get started
- Create two test tenants and build the thin slice.
- Write an automated test that crosses the boundary and run it on every release.
How Thinqmesh Solves This
We separate two questions: what the first version must prove, and what belongs in from the start. A first working version arrives within four weeks, and a launch-ready product is planned across twelve.
- Week 1
What the First Version Must Prove
We reduce your idea to a first version worth building and write down the tenancy, separation and roles that sit under it.
- Week 2
Accounts, Teams and Separate Data
Sign-up, login, invitations and roles are built, with each customer's data kept separate.
- Weeks 3 to 4
A First Working Version
The first version runs with monitoring and backups from its first release, so you can put it in front of a first customer.
- Weeks 5 to 12
Billing, Admin and Launch
Plans, payments, invoices, usage limits and admin tools are built and made dependable before customers arrive.
You finish with a launch-ready subscription product, separate and secure data for each customer, and admin tools for your support team. Source code and documentation are yours.
