Software

SaaS Platforms

Multi-tenant products built to survive their second year

How this is usually engaged

Typically an initial build to a first sellable release, then an ongoing arrangement as the roadmap becomes shaped by customers. We work equally with founding teams and with established organisations turning an internal tool into a product, though those are different problems and we scope them differently.

Practice
Software Engineering
Sectors
3 served
Process
5 stages
Standard
Built and tested to WCAG 2.2 AA

Summary

Subscription software with tenant isolation, billing that matches your commercial model, and the operational tooling a product needs once real customers depend on it.

01What this solves

The problem this addresses

The first version of a SaaS product is rarely the hard part. The difficulty arrives with the second year: tenants who need their data provably separated, a pricing change the billing code cannot express, a customer on an enterprise contract asking for single sign-on and an audit trail, and a support team who cannot answer basic questions because nothing was instrumented. Most of these are decisions made in the first month that nobody realised were decisions.

02Capabilities

What is included

01

Tenancy and isolation

The tenancy model chosen deliberately and enforced at the data layer, with a documented answer for the security questionnaire your first enterprise customer will send.

02

Subscription billing

Plans, seats, usage metering, trials, proration and failed-payment handling implemented against a payment provider, with billing state reconciled rather than assumed.

03

Onboarding and self-service

Sign-up, workspace creation, invitations and plan changes that customers complete without contacting you, because manual onboarding is the first thing that stops scaling.

04

Authentication options

Password and social sign-in for smaller customers, with SAML or OIDC single sign-on and directory provisioning where enterprise buyers require it.

05

Usage instrumentation

Product analytics and per-tenant usage data collected from the start, so decisions about pricing and roadmap rest on what customers do rather than on what they say in calls.

06

Support and operations tooling

Internal admin for tenant management, plan adjustment and diagnosis, so support questions are answered from a screen rather than from a database console.

03Use cases

Where this work usually starts

01

Taking an internal tool to market

Software built for one organisation that other organisations now want. The work is tenancy, billing and onboarding, not features.

Professional Services

02

A first product from a founding team

Getting to something sellable without the shortcuts that make the second year expensive, and knowing which shortcuts are safe to take.

03

Rebuilding billing that no longer fits

Pricing has changed three times and the code can only express the first version, so finance reconciles by hand every month.

Finance

04Approach

How we approach it

We settle the tenancy model early, because it is the one choice that is expensive to reverse — shared schema with enforced scoping, schema per tenant, or full isolation, chosen against your customers' actual requirements rather than a default. Billing is modelled against how you intend to charge, including the awkward cases of mid-cycle changes, proration and dunning. Onboarding, support tooling and usage instrumentation are treated as product surface from the start, not as internal extras to be added when the support queue makes them urgent.

05Process

How the work runs

The order matters more than the ceremony. Stages overlap in practice, but none of them is skipped.

  1. 01

    Commercial modelling

    How you intend to charge, and what has to be measurable for that to work. Pricing shapes the data model more than most teams expect.

  2. 02

    Tenancy decision

    Isolation model chosen against real customer requirements, with the trade-offs written down and agreed.

  3. 03

    Core build

    The workflow that makes the product worth paying for, built first and put in front of real users early.

  4. 04

    Commercial surface

    Billing, onboarding, plan management and support tooling — the parts that turn software into a product.

  5. 05

    Launch and iterate

    A controlled first cohort, close monitoring, and a roadmap reordered by what usage data shows.

06Deliverables

What you receive

Everything below is handed over as part of the engagement. If you take the work elsewhere afterwards, the next team has what it needs.

  • Tenancy and data isolation designThe model, its enforcement points and its documented limits.
  • Application, admin console and customer onboarding flow
  • Billing integration and test evidenceCovering upgrades, downgrades, proration, cancellation and failed payments.
  • Usage and product analytics instrumentation
  • Deployment pipeline, monitoring, alerting and backup restore test
  • Security questionnaire packFactual answers about architecture, data handling and access control, for your sales team to use.
07Technologies

What we use on this work

These entries are drawn from our managed technology directory, which records why each one is in our stack and what we reach for it for. Nothing outside this list is claimed for this service.

Languages & Runtimes

  • TypeScript

Frontend

  • React
  • Next.js

Data & Storage

  • PostgreSQL
  • Redis

Cloud Platforms

  • Amazon Web Services

DevOps & Operations

  • Sentry

Content & Commerce

  • Stripe
The full technology directory

Highlighted entries are used routinely on delivery work

08Security

How this is kept secure

Tenant scoping is enforced at the data access layer, so a missing filter in application code cannot return another customer's records. Sessions are server-side and revocable, and role assignment is per tenant rather than global. Administrative impersonation, where a support workflow requires it, is explicit, time-limited and logged with the reason. Encryption in transit and at rest, dependency scanning and a documented backup restore test are part of the build rather than a later hardening exercise.

09Questions

Asked before we start

Should we build multi-tenant or single-tenant?

Shared infrastructure with enforced tenant scoping is right for most products and much cheaper to run. Dedicated instances make sense when customers have contractual data residency or isolation requirements you cannot meet otherwise. We ask what your first ten target customers will demand in procurement, because that is the constraint, and the answer is rarely a technical preference.

Can you get us compliant with SOC 2 or ISO 27001?

We can build the technical controls those frameworks expect — access control, audit logging, encryption, change management, backup testing — and document how they work. We cannot make you compliant, because certification depends on organisational policy, evidence collected over a period, and an external auditor. Engage an auditor early and treat our work as the technical portion of a larger programme.

Do you take equity instead of fees?

No. We work on commercial terms, which keeps the relationship straightforward and means our advice is not shaped by a position in your company. If budget is the constraint, the more useful conversation is reducing the first release to the smallest thing you could genuinely sell.

How do you handle billing for a pricing model we have not settled yet?

We model billing so the common changes — new plan, changed seat price, added usage dimension — are configuration rather than code. What we cannot do is anticipate a change in billing basis, such as moving from per-seat to consumption, without rework. If you are genuinely undecided, launching with something simple and explicit beats building a flexible engine you may never use.

START HERE

Talk to us about SaaS Platforms

The project brief takes about five minutes and gives us enough to have a useful first conversation about SaaS Platforms rather than a generic one. If you would rather just ask a question, the short form is there for that.

We read every enquiry ourselves. If we are not the right fit, we will say so and tell you what to look for instead.