The three things you cannot retrofit cheaply.
Almost every SaaS rewrite we are called into has the same cause. Tenancy, billing and permissions were added after the first ten customers, at the point where changing any one of them means changing all three at once, on live data, with customers on it. Nothing about the framework choice caused that. Building those three first is unglamorous and it is the whole difference.
The problems that are specific to this sector.
Tenancy decided late is tenancy decided badly
How a tenant is isolated shapes the schema, the queries, the caching and the export path. Deciding it in month six means rewriting everything built in months one to five.
The first enterprise deal changes the product
SSO, role granularity, audit logs, data residency, a security questionnaire. These arrive together with the biggest contract you have been offered, and the answer cannot be six months.
Billing edge cases outnumber billing
Proration, mid-cycle upgrades, seat changes, failed payments, dunning, refunds. The happy path is a week; the rest is why finance stops trusting the numbers.
What we build for saas
- Multi-tenant architecture with isolation enforced in the data layer, not in code someone must remember
- Subscription billing through Stripe: plans, seats, proration, dunning, and invoices that reconcile
- A permission model your sales team can explain, plus SSO and SCIM for enterprise buyers
- Audit logging built before the first compliance questionnaire arrives, not after
- Admin and support tooling, so customer issues stop routing through engineering
What shapes the build
Requirements we design against in this sector. These describe obligations that apply to systems like yours — they are not claims that we hold a certification.
- SOC 2 readiness, which enterprise procurement asks about earlier every year
- GDPR obligations that follow your customers' customers, covering deletion, export and processor terms
- Data residency, once you sell into Europe or to a public-sector buyer with a jurisdiction requirement
- Uptime commitments, which turn into a real engineering budget the moment they are in a contract
The engagements this usually begins with.
Each says who it is for and, more usefully, who it isn't.
Custom SaaS Development
Multi-tenant platforms built to hold up under real customers, real load, and real compliance requirements.
What this involves ›MVP & POC Development
The smallest version of the idea that can still be judged, built in weeks and instrumented to tell you something.
What this involves ›DevOps Services
Pipelines, environments and observability, so shipping on a Friday stops being a brave decision.
What this involves ›AI Software Development
Products with a model at the centre of them, built with the evaluation and guardrails that keep them shippable.
What this involves ›Work we've done in saas.
The system we run our own business on
Rather than buy a CMS, a CRM, a proposal tool and an outreach platform, we built one system that does all four, and you are reading its front end right now.
Read the case study ›One database per customer, and twenty customers
Giving each customer their own database is a reasonable decision at three customers and an operational problem at twenty. Moving to a hybrid model keeps isolation where it is genuinely required and stops every new deal from adding infrastructure.
Read the case study ›Users leaving before they find the good part
A product with strong retention past ninety days loses a large share of signups in the first week, to a generic drip sequence that sends the same day three email whether or not the user got anywhere. Triggering on behaviour instead of on time fixes the mismatch.
Read the case study ›The ones this sector actually asks.
Can you take over a SaaS someone else built?
Often, and it depends on what is underneath. We read the code before quoting, and if rebuilding the tenancy layer costs less than untangling it, that is what we will tell you, including when it is the larger number.
How long to a sellable v1?
It depends on how much of the tenancy, billing and permission work is genuinely needed for your first ten customers. We scope it in phases with an exit after each, so the decision to continue is made repeatedly rather than once at the start.
Do we own the code?
In full, including the infrastructure definitions. No runtime licence, no hosting you are locked into, and nothing that prevents another team picking it up.
What is the most expensive thing your team still does by hand?
Tell us, and we'll tell you honestly whether software can fix it, and roughly what it would cost. No pitch deck.