Software & Platforms
The full domain, and the other capabilities within it.
SaaS Products
Multi-tenant products where tenancy, metering and release strategy are settled in the design, not discovered after the first enterprise customer.
What this is
A SaaS product is one codebase serving many customers, where isolation, billing and the release process are as much of the product as the features are. We build the tenancy model, the onboarding and self-service surface, the metering that billing depends on, and the delivery pipeline that lets you ship to everyone at once.
Multi-tenancy decided late is a rewrite; decided early it is a design choice. Teams that start single-tenant and plan to generalise later usually find the tenant boundary missing from every query, cache key, background job and log line. Metering is the second half of the same problem: if usage was never recorded as events, the first usage-based price change requires reconstructing history that does not exist.
When you need it
If more than one of these is true, this is usually the right place to start.
- You are running a separate deployment per customer, and every release multiplies the work.
- An enterprise prospect is asking about data residency, isolation and SSO, and you are not sure what your architecture will support.
- Billing is reconciled by hand each month because the system cannot say what a customer actually used.
- Every customer is on a slightly different version, so support cannot reproduce a bug without first asking which build they are on.
What the scope covers
- Tenancy model — shared schema, schema per tenant, or database per tenant — chosen against your isolation, residency and operational requirements.
- Onboarding and self-service: sign-up, tenant provisioning, user invitation, roles, and SSO for the customers who require it.
- Metering and billing integration, with usage recorded as immutable events that can be re-aggregated and audited.
- Feature flags and entitlements, separating what a tenant has bought from what has been deployed to them.
- Release strategy: trunk-based delivery, progressive rollout, and tenant-aware migrations that keep everyone on one version.
What you receive
| Deliverable | What it contains |
|---|---|
| Tenancy design | The isolation model written down with its residency, backup and noisy-neighbour consequences, including how a tenant is provisioned, exported and deleted. |
| Product application | The multi-tenant application, its onboarding and administration surfaces and its test suite, in your repository from the first week. |
| Metering and billing | Usage event capture, aggregation and the integration to your billing provider, with a reconciliation path between raw events and issued invoices. |
| Delivery pipeline | CI/CD with progressive rollout, tenant-aware migrations, feature flag management and observability segmented by tenant. |
Reference architecture
A reference, not a template. Your estate decides which parts apply and in what order they arrive.
How success is measured
Targets are agreed with you before the work starts, and reported against for its duration.
- Usage events captured against invoiced amounts, reconciled continuously so a metering gap is found before a customer finds it.
- Availability and latency reported per tenant as well as in aggregate, because one tenant's experience is not the average.
- Release lead time, rollout duration and rollback frequency, taken from the pipeline rather than estimated after the fact.
Questions we are asked
Which tenancy model should we use?
Shared schema with a tenant column is the cheapest to run and the easiest to get wrong, since one missing filter is a data leak. Schema per tenant gives clearer separation at the cost of running migrations across many schemas. Database per tenant answers residency and isolation demands but multiplies operations. We choose against your actual contractual requirements and write down what the choice costs.
Can we start single-tenant and add multi-tenancy later?
You can, and it is more expensive than it looks. The tenant identifier has to appear in every query, cache key, background job, file path and log entry, and adding it afterwards means touching all of them and trusting that none were missed. If you know more than one customer is coming, put the boundary in from the first sprint even while you deploy for one.
What if a customer wants their data held in-country?
That is handled as a deployment property rather than a code fork: the same build, deployed to a region, with tenant routing that knows where each tenant lives. It is straightforward if the tenancy model anticipated it and painful if it did not, which is why residency belongs in the first architecture conversation rather than in a later contract negotiation.
Do you integrate with billing providers?
Yes. A provider such as Stripe becomes the system of record for invoicing while your application remains the system of record for usage. The part that matters is storing usage as immutable events, so you can re-aggregate after a pricing change and explain any invoice from the underlying data rather than from a summary table.
How do you release without breaking customers?
Trunk-based development, backwards-compatible database migrations applied ahead of the code that needs them, feature flags to separate deploy from release, and progressive rollout starting with internal and low-risk tenants. Rollback is designed as a normal path, which means no migration is allowed to make it impossible.
What does it take to be enterprise-ready?
In practice: SSO with SAML or OIDC, SCIM provisioning, role-based access, an audit log the customer can read for themselves, data export and deletion, uptime commitments you can actually measure, and clear answers on subprocessors and residency. None of it is difficult in isolation. All of it is expensive to add under deal pressure, which is the argument for sequencing it before the enterprise pipeline builds.
Continue reading
Web Applications
Web applications built to an accessibility and performance budget from the first commit — architecture, API layer, CI/CD and observability you own.
Mobile Applications
iOS and Android applications where offline behaviour, sync and conflict rules, a backend for frontend and the store release pipeline are designed up front.
Start with an assessment
The fastest way to a useful answer is a short, scoped look at what you already have.