SaaS
SaaS development with tenancy, roles, and billing considered on day one
We build SaaS products for founders and companies turning an internal tool into something other organisations can use. Tenancy and permission boundaries are designed before features multiply across customers.
- Tenant model
- Product surface
- Onboarding
- Operational hooks
What has to be true before the second customer
One customer’s data must be unreachable from another customer’s session. Roles inside a tenant must be explicit. You need a way to provision, suspend, and export an account. Billing can be manual at first, but the account model should not make billing impossible.
A narrow first tenant
The first version should serve one painful job for a design-partner customer. Configurable everything is how SaaS products miss their date. Configuration arrives after two or three tenants have repeated the same request.
A product you can charge for
The first tenant
- Isolation between customers
- The roles that customer needs
- A way to invite, suspend, and export
After one customer is real
- A marketplace of add-ons
- Usage billing before the unit is defined
- White-label themes for buyers you do not have
What changes a SaaS build
Tenancy
Shared tables with a tenant key and a database per customer are different operations.
The commercial unit
Seat, location, or usage has to be named before the billing screen is drawn.
Your own admin
Support staff need a way to see a tenant without becoming that tenant by accident.
What a product brief needs
- 01
The first tenant
A real customer shape, not a hypothetical enterprise.
- 02
The commercial unit
Seat, location, or usage. One of them.
- 03
Isolation
What one customer must never see of another.
- 04
Your support view
How your own staff will help a tenant.
Marks a tenant product is safe to open
- 01
Tenants stay apart
One customer cannot read another customer’s data by changing an id.
- 02
The plan matches
What they pay for is what the product allows.
- 03
Onboarding finishes
A new tenant reaches the first useful screen without a manual setup call.
- 04
An admin can stop it
Suspend, export, and leave are possible for the account owner.
What we build
Tenant model
Isolation, ownership, and an admin path for your own support staff.
Product surface
The web app your customers live in, with audit on the sensitive actions.
Onboarding
Invite, first data import, and an empty state that explains the next step.
Operational hooks
Usage signals, feature flags, and a billing integration point.
How an engagement runs
- 01
Write the tenant rules
What is shared, what is isolated, and what support is allowed to see.
- 02
Ship to one design partner
A real organisation uses it, including the awkward import.
- 03
Prepare the second tenant
Provisioning and the fixes the first tenant forced into the open.
Questions we hear
Can you take over a SaaS that is already late?
Often. We start with tenancy risks, the release process, and the paths the current customers use. New features wait until those are understood.
Which stack?
Whichever your team can hire for and operate. Node.js, .NET, Python, and Java are all reasonable. The technology pages describe the trade-offs.
Do you help with pricing?
We can implement plans and limits. Commercial pricing is your decision. We will point out when the product cannot meter what you hoped to charge for.