Multi-tenant from the first line, because retrofitting it is a rewrite
Billing, trials, onboarding, per-tenant data isolation and the admin tools you need the day real customers arrive. We also model what each customer costs you to serve before the build starts, because that number decides whether the pricing works.
In short: Tenancy is an architecture decision, not a feature you add in month six. We build the tenant boundary, the billing, the signup path and the internal admin tooling as one connected thing, and we work out the cost of serving one customer before the first sprint rather than at the point where it starts to hurt.
Tenancy is a decision you make once
Every query in a multi-tenant product has to answer one question before it answers anything else: whose data is this? Get that boundary right at the start and it costs you almost nothing. Add it later and you are touching every table, every endpoint, every background job and every report at once. That is not a refactor. That is a rewrite with your existing customers still logged in.
So we settle it before the first feature. Shared database with enforced scoping, a schema per tenant, or separate databases for customers who contractually require it. Each has real trade-offs in cost, isolation and how painful a restore becomes when one customer asks to roll back a bad import. We pick with your buyers in mind. A product sold to hospitals answers a different question than one sold to freelancers.
Isolation enforced low
The tenant filter belongs in the data layer, not in each developer’s memory. One forgotten WHERE clause should be impossible, not merely unlikely.
One deploy, many customers
Per-customer branches of the codebase feel helpful early and become unmaintainable fast. Differences belong in configuration and feature flags.
Noisy neighbors
One customer importing a huge file should not slow everyone else down. Queues, limits and per-tenant quotas keep one bad afternoon contained.
Leaving as well as joining
Export and deletion for a single tenant, built early. Contracts and privacy rules will ask for it, usually at short notice.
Signup, trial, billing: the path that makes money
The first ten minutes decide most of it. A new account that lands on an empty screen with no data and no next step converts badly, so onboarding needs sample data, an import path, or a guided first task that produces something visible. Trials need a defined ending. What happens on the last day, what the customer can still see, and what they get back if they pay two weeks later are product decisions, and they should be made deliberately rather than discovered when the first trial expires.
Billing is where SaaS products get messy. Plan changes mid-cycle, proration, failed cards, dunning emails, tax by country, annual invoices for the customer whose finance team refuses card payment. We wire this to a payment provider rather than building it, then spend the effort on the parts that are genuinely yours: what a plan limit means, what happens when a customer crosses it, and whether they get blocked or gently warned.
The admin tools you need on day one
The first support ticket arrives long before the roadmap says it will, and it says something like: I cannot see my report. Answering that without an internal tool means someone opening a database console in production, which is how accidents happen. So we build the back office alongside the product: find an account, see its plan and its usage, view what the customer sees with an impersonation mode that is logged, extend a trial, apply a credit, suspend, reactivate.
This tooling is unglamorous and it is the difference between support taking minutes and taking a developer’s afternoon. It also keeps your own access honest, since every action taken on a customer account leaves a record with a name attached.
Cost per customer decides whether the margin works
A product can grow and still lose money on every account. Storage, database load, background processing, third-party API calls billed per request, egress, log retention: none of it is dramatic on its own, and together it sets the floor under your pricing. If a heavy customer costs more to serve than the plan they are on, growth makes the problem bigger rather than smaller.
We model this before the build. Take the heaviest realistic customer, estimate what they consume, and check the plan price against it. That exercise changes designs. It might mean tiering storage, batching an expensive external call, capping something in the free plan, or putting a usage element into the pricing. Instrumenting usage per tenant from the beginning matters too, because you cannot price what you never measured. Where the running cost sits mostly in infrastructure choices, our cloud and DevOps team works the same numbers from the other side.
What we won’t do
We won’t skip the tenancy model to hit a demo date
Single-tenant code written to impress an investor in three weeks becomes the thing you pay for over the next two years. If the deadline leaves no room for the boundary, we will argue for a narrower demo instead.
We won’t invent your pricing model for you
We can show what each plan costs to serve and what the metering would have to measure. What a customer will actually pay is your commercial call, and building elaborate usage billing before that call is made wastes money.
We won’t launch a product with no way to support it
If admin tooling keeps getting pushed behind features, we will say that the launch is not ready. Debugging live customer accounts through raw database access is a habit that ends badly.
Do you know what your heaviest customer will cost you?
Bring us the product idea and the pricing you have in mind. We will work through tenancy, billing and cost per account before anyone writes code.
Can you make our existing single-tenant app multi-tenant?
Sometimes, and it is rarely small. Adding a tenant boundary after the fact touches the schema, the queries, the background jobs and the reports together, so we scope it as its own project with a migration plan for the customers already on the system.
Should we build billing ourselves?
Almost never. Cards, retries, tax and invoices are solved by payment providers and staying current with them is a full-time job. We integrate one and put the effort into plan limits and what happens when a customer crosses them.
When should we model infrastructure cost per customer?
Before the build, using the heaviest customer you realistically expect. The answer often changes the design, and finding it at scale instead means repricing customers who already signed a contract.
How much product should be in the first release?
Enough for one customer segment to do the job they are paying for, with signup, billing and admin tooling working properly. Breadth added before that is usually the part rewritten after the first paying customers arrive.
