Skip to main content
All services

SaaS Products

One codebase.Every tenant.

Architecture through launch: multi-tenancy, subscriptions, dashboards, and the operational tooling a product needs to be run by a real team.

  • Multi-tenant
  • Billing
  • Dashboards
  • Auth
  • TENANTS · PLATFORM · RENEWAL
  • SIX TIERS
  • ISOLATED BY DESIGN

SaaS Products.

  1. 01TenantIsolated by design
  2. 02ProductThe same codebase for all of them
  3. 03SubscriptionWhere the model actually lives
  4. 04RenewalEarned again every month

A SaaS product is two things at once. It is software, and it is a business model that bills on a schedule — and the second one changes how the first has to be built. One codebase serves every customer, so a bug ships to all of them; one deployment runs for everyone, so downtime is not a customer-by-customer conversation; and revenue depends on a renewal that has to be earned rather than closed.

That puts an unusual amount of weight on decisions that look like plumbing. Where the tenant boundary sits, and whether it is enforced by a policy or by the database. What a plan actually unlocks, and where that check lives. What happens when a card fails on a Sunday. Whether your support team can see what a customer sees without asking them for a screenshot.

So we build the parts a product needs to be run, not just launched: isolation you can prove, billing that survives a failed payment, entitlements that are one decision rather than forty scattered conditionals, and the internal tooling that stops every support question becoming an engineering ticket.

Capabilities

What we actually build.

Engagements are usually a subset of this list, scoped to where the product is. This is engineering work on your platform — not a boilerplate we resell and not a template with your logo on it.

01Multi-Tenant Architecture
The tenant model and the isolation that enforces it — carried in the data layer rather than remembered by the application — plus the cross-tenant tests that turn “customers cannot see each other's data” from a claim into something demonstrable.
02Authentication & Organisations
Sign-up, sign-in, organisations, teams, invitations, seats and roles, including the cases that arrive later: a user in two customers, an owner who leaves, and the enterprise buyer who asks for SSO during procurement.
03Subscriptions & Billing
Plans, trials, proration, upgrades, invoices and tax, with provider events reconciled server-side so subscription state is never trusted from the browser. Includes the failure paths — failed cards, dunning, and recovery — that decide real revenue.
04Entitlements & Plans
One place that answers what a plan unlocks, so a pricing change is a configuration change rather than an archaeology project. Feature gates, usage limits, trial and grace behaviour, and upgrade paths that do not lose a customer's work.
05Admin & Operations
The internal product your team runs the business from: scoped and audited support access, per-tenant visibility, tenant-wide migrations, and the tooling that stops every support question turning into an engineering ticket.
06Product Analytics
Instrumentation aimed at whether a customer got value — activation, depth of use, and the signals that precede a cancellation — rather than a dashboard of totals that goes up regardless of what is happening.

Where an off-the-shelf platform genuinely covers what you need, we will say so. Building billing or authentication from scratch is rarely the right call, and the engineering is in wiring them correctly rather than replacing them.

Product architecture

One platform, isolated per tenant.

Every customer runs the same code and sees only their own data. That sentence is easy to write and is decided in six places — this is where each one sits, what it is responsible for, and whether it is isolated per tenant or shared by all of them.

04 per tenant · 02 shared

06 tiers · 30 controls

  1. 01

    Tenant

    The isolation boundary

    Per tenantDatabase04

    Which customer a row belongs to, and how that is enforced. Isolation carried in the data layer rather than remembered by the application, so a missing filter is a rejected query instead of a leak. The boundary is testable: a request authenticated as one tenant should be able to prove it cannot read another.

    • Tenant model
    • Row-level isolation
    • Query scoping
    • Cross-tenant tests
    • Data export and deletion
  2. 02

    Identity

    Who is in the tenant, and what they may do

    Per tenantBackend05

    Organisations, teams, invitations, roles and the seat model — plus the awkward realities: a person belonging to two customers, an owner who leaves, and an enterprise buyer who will ask for SSO before they sign. Permission models are the part of a product that quietly rots as the customer's team grows.

    • Organisations and teams
    • Invitations and seats
    • Role model
    • Session and token handling
    • SSO readiness
  3. 03

    Product

    The surface everyone shares

    SharedFrontend05

    One codebase, one deployment, every customer. That is the efficiency of the model and also its risk: a regression ships to all of them at once. So the surface is built to be released continuously and turned on selectively — feature flags, staged rollout, and dashboards that stay legible when a customer's account is empty on day one.

    • Shared codebase
    • Feature flags
    • Staged rollout
    • Onboarding and empty states
    • Dashboards and reporting
  4. 04

    Entitlement

    What this plan actually unlocks

    Per tenant

    The join between what a customer pays for and what the product lets them do. It belongs in one place: a single decision the product asks rather than forty conditionals scattered through it. This tier has no technology chip because it is a policy, not a vendor — and treating it as a vendor's problem is how plan logic ends up unauditable.

    • Plan definitions
    • Feature gates
    • Usage limits
    • Trial and grace periods
    • Upgrade and downgrade paths
  5. 05

    Billing

    The recurring contract

    Per tenantIntegrations07

    Plans, trials, proration, invoices, tax, and the unglamorous half nobody demos: a card that fails on a Sunday, a webhook that arrives twice, and a subscription state that must agree with the provider's even after a timeout. Provider events are reconciled server-side rather than trusted from the browser.

    • Plans and pricing
    • Proration and trials
    • Webhook reconciliation
    • Dunning and recovery
    • Invoices and tax
  6. 06

    Operations

    Running it for everyone at once

    SharedInfrastructure04

    The tooling a team needs to operate a product they did not write today: support access that is scoped and audited rather than a shared admin login, per-tenant visibility when one customer reports something, migrations that run for all tenants safely, and the usage signals that show activation rather than vanity.

    • Admin tooling
    • Audited impersonation
    • Per-tenant observability
    • Tenant-wide migrations
    • Usage and activation signals
Stage 01
Tenants00:01
Stage 02
Usage00:05
Stage 03
Renewal00:06
Source
1920 × 108030fps · 1.33MB

Still frame

Tenant · Identity · Product · Entitlement · Billing · Operations

Product lifecycle

How the work is sequenced.

The order matters because two of these are almost impossible to retrofit. Tenancy decided after launch means a data migration under load, and entitlements decided late means finding every conditional that guessed.

  1. 01

    Model

    Decide the tenant boundary first.

    What a tenant is, what belongs to one, and how isolation is enforced. This is the decision that is hardest to change once real customer records exist, so it is made deliberately and written down rather than emerging from the first feature.

  2. 02

    Shape

    Plans and permissions before features.

    What the plans are, what each unlocks, and who inside a customer can do what. Pricing will change — the point is that entitlement is one decision the product asks, so changing it later is configuration rather than excavation.

  3. 03

    Build

    The product and the money together.

    The surface, the subscription lifecycle and the entitlement checks built as one system, because a product whose billing was added afterwards is a product with two sources of truth about what a customer is allowed to do.

  4. 04

    Operate

    Give the team something to run it with.

    Admin tooling, scoped support access, per-tenant visibility and the usage signals that show activation. This is the stage most often cut, and the one whose absence is felt every single day after launch.

  5. 05

    Iterate

    Ship continuously without breaking everyone.

    Feature flags, staged rollout, tenant-wide migrations that run safely, and dependency upkeep. One codebase means one regression reaches every customer, so releasing has to be routine enough to be frequent.

Built to be operated

What makes it runnable.

A SaaS product is not delivered, it is operated — every day, by people who did not necessarily build it. These are the properties that decide whether that is a calm job or a permanent emergency, and they are the ones we would ask about if we were buying this work.

01Isolation you can demonstrate
Enforced where the data lives, not remembered by the caller, and covered by tests that authenticate as one tenant and prove they cannot reach another. The first question a serious buyer asks, and it deserves a demonstrable answer.
02One source of truth for money
Subscription state reconciled from provider webhooks server-side, idempotent against duplicate events, and never inferred from the browser. What a customer is entitled to should not depend on which page they last loaded.
03Entitlement in one place
A single decision the product asks, rather than conditionals scattered across the codebase. It is what makes a pricing change a configuration change instead of a fortnight of archaeology.
04Releasing without a maintenance window
Feature flags, staged rollout, and migrations designed to run forward while the system is serving. One deployment serves every customer, so downtime is not a per-customer conversation.
05Support that does not need an engineer
Scoped, audited access to see what a customer sees, and per-tenant visibility when one of them reports a problem. Without it, every support question becomes an engineering ticket and the roadmap stops.
06Leaving is part of the product
Export and deletion that actually work, because a customer who cannot get their data out is a customer who tells other people. It is also the part regulators and procurement teams ask about first.

What we build

Shapes of product this work suits.

These are product shapes rather than case studies — the situations where the SaaS-specific architecture is the deciding factor. Our published project work lives under Selected Work; nothing below is presented as a delivered engagement.

01A first commercial product
Going from an idea, a prototype or a services business to something that can be signed up for, billed and supported without a person in the loop for every account.
02An internal tool becoming a product
Software built for one organisation that other people now want. The work is almost entirely tenancy, identity and entitlement — the features already exist and were never designed to be shared.
03B2B with organisations, not just users
Where the customer is a company: teams, seats, roles, an admin who manages other people, consolidated billing, and the SSO conversation that arrives during procurement.
04A pricing model that has to change
Moving between per-seat, usage-based or tiered pricing, where the real problem is that entitlement was never a single decision and the plan logic is spread across the product.
05A product a team cannot operate
Where every support request needs an engineer with database access. The work is admin tooling, scoped support access and per-tenant visibility, so the team can answer its own questions.
06A single-tenant system that has to multiply
One deployment per customer that has stopped being affordable to run. Consolidating onto one tenant-aware platform, usually incrementally, and usually the hardest migration on this list.

Systems layer

What it is built on.

Read from the same engineering stack the rest of the site publishes, not a separate list for this page. Payment and identity providers appear because they are already in that stack — provider choice is an engagement decision, and the integration is written so it can change.

01Frontend05The product surface and the dashboards a customer runs their day in
  • React
  • Next.js
  • TypeScript
  • Tailwind CSS
  • React Native
02Backend05Where tenancy, roles and entitlement are actually enforced
  • Node.js
  • Python
  • REST APIs
  • GraphQL
  • WebSockets
03Database04Where isolation stops being a policy and becomes a row-level fact
  • PostgreSQL
  • Redis
  • Supabase
  • Vector Databases
04Integrations07Payments and identity — the systems the business model depends on
  • Stripe
  • Paystack
  • Flutterwave
  • Third-party APIs
  • Webhooks
  • OAuth
  • Message Queues
05Cloud04One deployment serving every customer at once
  • AWS
  • Vercel
  • Cloudflare
  • Object Storage
06Infrastructure04Shipping to all tenants at the same time, without asking them first
  • Docker
  • CI/CD
  • Observability
  • Infrastructure as Code

Building something peoplewill pay for monthly?

The most useful first conversation is about the tenant boundary and what a plan unlocks — the two decisions that are cheap now and expensive once real customers exist.

Start a ProjectAll services