SaaS Development

A product you can sell, architected before the first customer.

Tenancy, billing and permissions are architectural decisions, not features to add later. Retrofitting them is where SaaS builds go badly wrong, and it is almost always more expensive than settling them at the start.

The three decisions

How tenants are isolated, how usage becomes revenue, and who can see what. Almost everything else in a SaaS product can be changed later. These three cannot be changed cheaply.

Tenancy is the first decision, not a later one

Shared schema, schema-per-tenant or database-per-tenant is not a preference. It follows from your isolation requirements, the size distribution of your customers, and what your largest prospect's security review is going to ask for.

We make that call explicitly and write down what it costs, because migrating between them afterwards is a project of its own — usually one that has to happen under load.

Billing that matches what you actually sell

Plans, seats, usage, trials, mid-cycle upgrades, proration, failed payments, dunning. Billing looks like a checkout page and is really a state machine that has to stay in agreement with your ledger.

We build it as a state machine and we make it reconcilable, so the invoice, the entitlement and the access a customer has all derive from the same source rather than from three that drift.

Admin tooling is not optional

The tools your own team needs — impersonation, plan changes, refunds, usage inspection, feature flags — decide whether support scales or consumes engineering.

They go into the first release rather than the fourth, because a product without them generates a support queue that only engineers can serve, and that cost compounds with every customer.

In practice

Tenancy, billing and permissions are architectural decisions, not features to add later — retrofitting them is where SaaS builds go badly wrong. We settle them before the first screen is designed.

What a build includes

  • Tenancy model
  • Subscription & billing
  • Admin tooling
  • Usage metering
  • Deployment pipeline
Our position

Where SaaS builds go wrong

Three failures we have seen often enough to design against by default.

  • Billing bolted on at the end

    Entitlements end up derived from three places that disagree, and the first refund is what exposes it.

  • No metering until pricing changes

    You cannot price on usage you never recorded. Metering goes in before anybody needs the numbers.

  • A single-tenant build called multi-tenant

    It works until the second customer, and the fix is a data migration with production traffic on top of it.

Building something you intend to sell?

Tell us the shape of the product and who buys it. The tenancy and billing answers follow from that, and they are worth getting right first.