Skip to content

SaaS product development

The hard parts of a SaaS product are rarely the features on the marketing page. They are tenancy, billing, permissions, and what happens on the unhappy paths — and each one is dramatically cheaper to design in at the start than to retrofit once you have paying customers who cannot be interrupted.

Start a project
Tested & documentedYou own the code

Tenancy is an architectural decision, not a feature

Every multi-tenant product picks an isolation model, whether deliberately or by accident. A shared schema with a tenant column is simple and scales well, but every query becomes a place to leak another customer's data if the scoping is not enforced centrally. A database per tenant isolates cleanly and makes migrations, backups, and connection limits a standing operational cost.

Neither is universally right. What matters is choosing on purpose, enforcing it in one place rather than in every query, and testing that the boundary actually holds. A cross-tenant data leak is the one bug a B2B product may not survive commercially, and it is almost always a scoping mistake in a query somebody wrote in a hurry.

Billing that reflects how you actually sell

Subscription billing looks solved until you meet the real requirements: mid-cycle upgrades, proration, annual plans with monthly add-ons, seats that change during a period, trials that convert, and the long tail of failed payments. The payment provider handles the money. The logic about what a customer is entitled to, and what happens when they stop paying, is your product, and it belongs in your codebase where it can be tested.

The unhappy paths matter most

Payment fails. A card expires. A tenant cancels and comes back two months later. Someone downgrades to a plan that does not permit the data they already have. These are the cases that generate support load and refund requests, and they are the cases most likely to be missing from the specification. We ask about them early.

Permissions before you need them

Products that launch with one user type acquire more. The customer who wants a read-only account for their accountant, the team that needs an admin who cannot see salaries, the enterprise buyer who asks about SSO. Modelling roles and permissions as a real concept from the start costs little; discovering later that authorisation is scattered across controllers and templates is an expensive audit.

Instrumentation from the first release

You cannot improve activation or reduce churn without knowing where people stop. Usage tracking, per-tenant reporting, and error monitoring belong in the first release, not the version where you finally have time. They are also what turns a renewal conversation from an opinion into a demonstration.

Common questions

Should we launch with multi-tenancy or add it later?
Decide the isolation model before launch, even if the first version has one customer. Retrofitting tenancy into a single-tenant schema means touching every query, every index, and every background job at exactly the moment you are least able to afford downtime. Choosing the model early is cheap; changing it later is not.
Do you build the billing yourself?
No — we integrate a payment provider such as Stripe rather than handling card data ourselves, which keeps you out of PCI scope. What we build is the part that is specific to you: your plan structure, proration rules, trials, upgrades, dunning behaviour, and what happens to a tenant when payment fails.
How long before we can put it in front of customers?
That depends on scope, but the goal is always a genuinely usable slice rather than a demo. We would rather ship one workflow that a real customer can complete end to end than five that each stop halfway. The first release is normally sign-up, the core workflow, and billing.
What about compliance and data residency?
Tell us early. Requirements like data residency, audit logging, or SOC 2 readiness are architectural, not features. They change how you store data and what you record, and they are considerably cheaper to design in than to add once you have customers.

Have something worth building?

Tell us what you are trying to ship and what is in the way. We reply within one business day.

Start a conversation