Service
SaaS that holds up in the second year
SaaS development for teams selling software as a subscription. We build the multi-tenant core first — isolation, entitlements, roles, audit, onboarding, observability — so adding a customer stays a routine event, not an architectural one.
The Problem
The first release is the easy part
Most SaaS products demo well and operate painfully. The trouble is rarely in the feature list — it sits in the tenancy model, the billing logic and the parts nobody wrote into the budget.
- 01
Tenancy bolted on later
A tenant column added after launch touches every query, every background job and every report. Until it reaches all three, one customer's data sits a missing filter clause away from another's.
- 02
Billing that disagrees with the product
Plans live in the payment provider, limits live in the application code, and nobody can state what a downgraded account may still do. Support settles each case by hand.
- 03
No record of what happened
When a customer asks why a record changed or an invoice moved, the evidence is whatever the production logs happened to keep. Security reviews ask for that history in writing.
The Approach
Build the load-bearing parts first
Tenancy, entitlements and auditability are foundations rather than features. Each is cheap to decide in the first week and structural surgery once a product has customers.
- 01
Isolation decided once
Tenant boundaries are enforced in the data layer, not in each query a developer remembers to filter. Shared schema, schema per tenant or database per tenant — chosen against your compliance and cost profile, then applied everywhere.
- 02
One source of truth for entitlements
Plans, seat counts, limits and flags resolve from a single service that the product and the payment provider both defer to. A downgrade then takes effect in the product by itself.
- 03
Instrumented before launch
Structured logs, traces and per-tenant metrics are part of the build, so an early incident is diagnosed instead of guessed at. We will say when a feature is worth less than the instrumentation it needs.
Capabilities
What we build beneath your features
The layer under the product — needed by every SaaS, seldom written into a brief, and usually discovered at the worst moment.
-
Multi-tenancy
Tenant modelling, isolation pushed below the application, tenant-aware routing and background jobs, and a documented route for moving a large customer onto their own boundary later.
-
Billing and subscriptions
Trials, plan changes, proration, seat counting, usage metering and failed-payment handling wired to a payment provider, with the product keeping its own ledger of what each account owes.
-
Roles and permissions
Permission models that survive real org charts: per-tenant roles, delegated administration, scoped API tokens, and one authorisation check rather than a copy in every controller.
-
Audit and evidence
Durable records of who changed what, when and from where — queryable by your support team, exportable for customers under their own compliance obligations, kept for a retention window you choose.
-
Onboarding and provisioning
Sign-up, workspace creation, seed data, invitations, SSO and domain verification as one automated path, so a new account is live before anyone on your side reads the notification.
-
Observability and release safety
Per-tenant dashboards, error tracking, feature flags and reversible migrations, so a change can be narrowed to the accounts it affects and withdrawn without a full redeploy.
Technologies
What we tend to build with
Tools chosen for the operational load they remove. The stack follows the product and the team who will maintain it, but these are the ones we reach for most often.
Application
Data
Billing and identity
Platform and operations
How we work
From pricing model to operating platform
- Step 01
Tenancy and pricing model
Before any schema exists we settle what a tenant is, how deep isolation has to go, and what you actually charge for. Those three answers constrain everything built afterwards.
- Step 02
Platform core
Identity, provisioning, the authorisation layer and the entitlement service are built and tested before any customer-facing screen. Product work then sits on top of those decisions.
- Step 03
Product surface
The functionality customers are actually buying, built on that core. Each feature inherits isolation, roles, audit and limits, so one rule is never implemented three slightly different ways.
- Step 04
Commerce paths, including the unhappy ones
Checkout, upgrades, downgrades, cancellation and reactivation wired end to end. Expired trials, declined cards and seats removed mid-cycle are tested as first-class states, because customers meet them.
- Step 05
Launch, then the operating work
We release with per-tenant telemetry, support tooling and runbooks in place, then stay on the migrations, limit changes and infrastructure costs that only show up once the platform carries weight.
Have a product to build?
Tell us who the tenants are, what you charge for, and where the current system strains. The reply will say what we would build first, and what can safely wait.