Services
SaaS & Platforms
Multi-tenant products built to carry real customers
Most of what we ship is multi-tenant SaaS — products with org boundaries, role hierarchies, billing, admin tooling and white-label surfaces. We build them so the fiftieth customer costs the same to onboard as the first, because the difference between a platform and a well-dressed prototype is whether growth costs engineering time.
We have taken products from an empty repository to production traffic, and we have taken over platforms where tenancy was retrofitted and every new customer required a developer. Both jobs come down to the same thing: getting the boundaries right, then making the operator surfaces as good as the customer ones.
You probably need this if
- Onboarding a new customer requires an engineer to run a script or touch config
- White-labelling means maintaining a fork or a pile of conditional branches
- Support cannot see what a customer sees, so every bug report becomes a guessing game
- Permissions are checked in the UI, and nobody is confident about what the API allows
- Billing and entitlements disagree, so people keep access they stopped paying for
Tenancy is the decision you cannot cheaply reverse
Almost every expensive SaaS rebuild we have inherited traces back to the same root cause: the tenancy model was decided implicitly, usually by whoever wrote the first database migration. Once customer data, permissions and billing have grown around a weak boundary, separating them is a rewrite rather than a refactor.
So we settle it first. Which entities are tenant-scoped, which are global, how isolation is enforced at the data layer rather than by remembering to add a filter, and what happens when one customer needs to see across several orgs. It is unglamorous work that takes days and saves quarters.
- Isolation enforced at the data layer, not by developer discipline in each query
- Org, workspace and user hierarchies modelled before feature work begins
- Cross-tenant access designed deliberately for agencies, parents and resellers
- Migration paths planned for when a customer splits, merges or is acquired
White-label as data, never as a fork
White-label goes wrong when branding is treated as a deployment concern. You end up with a fork per customer, and every fix has to be applied several times until someone misses one and a customer sits on a stale build for months.
We model branding, domains, theming, email identity and feature entitlements as tenant data. A new white-label workspace is a record, not a release. That is how Treply supported agency partners running their own branded consoles on top of one codebase.
- Brand, domain, theme and email identity stored as tenant configuration
- Agency and reseller consoles that manage their own downstream customers
- Entitlements driving what each tier can see, on the server and not just the UI
- One deploy serving every brand, so fixes land everywhere at once
Operator surfaces are product, not internal tooling
The admin console decides whether your company can actually run the product. When support cannot reproduce a customer's view, every ticket escalates to engineering, and your senior developers spend their week doing customer service with database access.
We build the operator side in step with the customer side. Impersonation with an audit trail, tenant-level analytics, manual overrides for the cases the product does not cover yet, and the ability for sales to provision an account without filing a ticket.
- Impersonation with full audit logging so support sees exactly what the customer sees
- Tenant provisioning and configuration usable by non-engineers
- Usage and health analytics per tenant, surfaced before customers complain
- Safe manual overrides for the edge cases every real business has
Billing wired to the same truth as permissions
When billing state and access control live in separate systems, they drift. Customers churn and keep access, plans upgrade and features stay locked, and finance reconciles by hand every month.
We wire entitlements to the same source of truth the permission layer reads, so a plan change immediately and correctly changes what the customer can do. Trials, proration, seat counts and usage limits all resolve through one path.
How the work runs
Architecture read
One to two weeks. We map the tenancy model, permission surface, billing path and integration boundaries — whether that is a blank page or an existing codebase. You get an honest written assessment, including the parts we think are fine.
Foundation
Tenancy, auth, roles and the deployment pipeline land first, with a thin but genuinely working feature slice on top so the model gets tested against reality rather than a diagram.
Surface build
Customer app, operator console and billing get built in parallel rather than sequenced, so the product is operable the day it is usable.
Scale and hand back
Load characteristics, monitoring and documentation. Your team can run and extend the platform without us, which is the point.
What you get
- —Production multi-tenant application in your repositories and infrastructure
- —Admin and operator console with impersonation and audit trails
- —Billing and entitlement integration tied to the permission model
- —White-label and theming layer where the engagement calls for it
- —Deployment pipeline, monitoring and written architecture documentation
What we will not do
- —We do not run long discovery phases before engineers are in the codebase
- —We do not take ownership of your infrastructure accounts — they stay yours
- —We will tell you when a rebuild is not warranted, even though rebuilds bill more
Where we have done this
Common questions
Can you fix tenancy on a product that is already live?
Usually yes, and we have done it. It is done in phases behind live traffic rather than as a cutover — new boundaries go in alongside the old ones, data migrates in stages, and the old path is removed last. It is slower than a rewrite and far less risky.
Do you work with our existing stack or impose one?
We work with what you have unless there is a concrete reason to change it. Replacing a stack that works is expensive and mostly serves the agency, not the client.
How long until something is usable?
For greenfield, weeks rather than months to a working slice you can click through. We deliberately avoid long stretches where the only visible output is documents.
Need this on your product?
Tell us where delivery is stuck. We will give you an honest read on scope and shape before anyone talks contracts.
Book a technical review