Software Development

SaaS Product Development

Multi-tenant products built to be changed.

Every SaaS product has the same foundation underneath the thing that makes it distinctive: tenants, users, roles, subscriptions, invoices, onboarding and an admin view for support. That layer is largely identical across products, and it is expensive to get wrong because it is load-bearing.

We build that foundation properly and then the part that is actually your product on top of it. The distinction matters: the foundation should be conventional and boring, because novelty there buys nothing and costs a great deal.

The work covers tenancy and data isolation, role and permission models, subscription billing with the awkward states handled, self-service onboarding, and the internal tooling your support team needs to answer a customer question without a developer.

At a glance

Typical stack: Laravel Next.js TypeScript PostgreSQL Redis AWS Docker
Common industries: SaaS & Startups
Engagement: Fixed scope, dedicated team, or staff augmentation

Request a quote

No obligation. We will tell you if it is not a fit.

The problem

What this solves

Two decisions in a SaaS product are close to irreversible: how tenants are isolated, and how permissions are modelled. Both are cheap at the start and extremely expensive once there is customer data spread across the assumption.

Billing is the other reliable source of pain. It looks like an integration and behaves like a domain. Mid-cycle plan changes, proration, failed payments and retries, cancellations that should keep access until period end, refunds and tax all arrive with the first real customers, and improvised handling produces disputed charges rather than clean errors.

Tenancy decided by accident

The isolation model emerges from early code rather than being chosen, and cannot be changed later.
Permissions enforced in the interface

Hidden buttons with unprotected endpoints behind them — the most common serious SaaS defect.
Billing edge cases deferred

Proration, dunning and mid-cycle changes handled by hand, producing disputes rather than errors.
No support tooling

Every customer question becomes a developer running a database query.

Our approach

How we go about it

We decide the tenancy model against the customers you expect to have in two years, not the ones you have now. Shared database with enforced scoping is right for most products; separated schemas or databases are right when isolation, residency or export requirements are coming. Whichever it is, isolation is enforced at the query layer so a route added later cannot bypass it.

Permissions are modelled explicitly and checked on the server on every path. Hiding a button is presentation; the check that matters is the one on the request.

Billing is built against the provider's webhooks as the source of truth, handled idempotently and reconciled rather than trusted. The unglamorous states are implemented and tested up front, because they are not edge cases — they are the second month.

Capabilities

What is included

Multi-tenant data architecture and isolation
Subscription billing and plan entitlements
Self-service onboarding and trial flows
Usage metering and quota enforcement
Admin tooling for support and account management
Analytics instrumentation for activation and churn

Outcomes

What changes for you

Isolation enforced at the query layer

Scoping that a new route cannot accidentally bypass, rather than discipline applied per controller.
Server-side permission checks

Every path authorised on the request, with the interface merely reflecting the same rules.
Billing states that actually exist

Failed payments, upgrades, downgrades, cancellations and reactivations built and tested before launch.
Support can self-serve

An admin view that answers the common questions without a developer or a raw query.

Related work

Where we have done this

All case studies

Frequently asked questions

Common questions about saas product development.

Which billing provider do you recommend?

Usually whichever handles tax and compliance for the markets you sell into, because that is the part you least want to own. The integration work is comparable across the main providers; the difference is in whether they act as merchant of record and handle VAT or sales tax for you. That decision is commercial more than technical.

Can we start shared and separate tenants later?

It is possible but it is a migration project rather than a configuration change, and it happens at the worst time — when a large customer is asking for it during a deal. If you can see enterprise customers in your future it is much cheaper to build the seam now, even if every tenant currently shares one database.

How do you handle single sign-on for enterprise customers?

By keeping the authentication path pluggable from the start, so adding SAML or OIDC for a specific tenant does not mean unpicking the login flow. It is not usually worth building before the first customer asks, but it is very much worth not designing it out.

Related services

Building a subscription product?

The tenancy and billing decisions are the ones worth an hour of conversation before any code exists.

Start a project Talk to our team