SaaS development services
Every SaaS business eventually hits the same wall, and it is almost never features. It is a tenancy model that will not isolate a customer who now demands it, a billing system that cannot express the plan sales just sold, an auth model that breaks the moment an enterprise buyer asks for SSO, and infrastructure costs that grow faster than revenue. We design and build SaaS products, and take over existing ones, so those walls arrive later, or not at all.
The expensive decisions
Everything else in a SaaS product can be changed later without much pain. These four cannot, and every one of them is usually decided in the first fortnight by whoever happens to be writing that file.
How customer data is separated determines what you can sell, to whom, and at what infrastructure cost. Moving from pooled to isolated after you have a thousand tenants is a migration project measured in quarters, not a configuration change. We pick the model against your actual sales motion, not the one that is fashionable.
If usage is not measured from the first day it is essentially unrecoverable, because you cannot bill retroactively for data you never captured. Plans, seats, usage tiers, overages, trials, proration and mid-cycle upgrades all need to exist in the data model before sales invents a plan that breaks it.
Consumer-style email and password gets you to your first enterprise deal and no further. SSO, SCIM provisioning, role models and per-tenant administration are the difference between an enterprise contract closing and stalling in security review.
The infrastructure cost of serving one customer, known per tenant rather than as one monthly bill. Without it you cannot price with confidence, spot the customer who is unprofitable, or tell an investor what your gross margin actually is.
Tenancy
There is no universally right answer here. There is only the right answer for what you are selling, to whom, and under which regulations. This is usually the first serious conversation we have with a SaaS client.
One application, one database, every row tagged with a tenant identifier.
Cheapest to run and simplest to operate. Best for high-volume, lower-price products where customers are not asking hard questions about data separation.
Risk: one bad query can cross tenants. Row-level security and query-level guards are mandatory, not optional.
One application, a separate database per tenant.
The pragmatic middle, and where most B2B products should start. Strong data separation, per-tenant backup and restore, and a credible answer in a security questionnaire.
Cost: schema migrations must run across every tenant database, so migration tooling has to be solid from day one.
A complete stack for each tenant.
For regulated or high-value customers who require it contractually, and for data residency in a specific jurisdiction. Often sold as a premium tier rather than the default.
Cost: operationally expensive. Only worth it when a customer is genuinely paying for the isolation.
Who it is for
Founders and product leaders building a product to sell to many customers, and teams whose existing product has started to strain. If you are still testing whether anyone will pay, start smaller.
What we build
The tenancy model, isolation guarantees and the migration path between them, designed so you can move a single customer to stronger isolation without rebuilding the product.
Plans, seats, usage tiers, trials, proration and overages, integrated with your payment provider and reconciled against what the system actually metered.
The features that unblock an enterprise deal, built before the deal rather than during it while the buyer waits.
Signup, trial, activation and upgrade paths that work without a human, so your sales team spends its time on the deals that need it.
Instrumentation that answers which features drive retention and which cost you money, rather than a dashboard of vanity metrics.
Capacity that follows demand, noisy-neighbour protection, and the observability to know which tenant is causing a problem.
Their technical team worked closely with us to understand our user base and designed models using TensorFlow and PyTorch that integrated flawlessly with our web app.
How we ship it faster
SaaS products carry an enormous amount of necessary but unremarkable work: the billing state machine, the invitation and role plumbing, the admin surfaces, the webhook handlers, the integration adapters, the test coverage across every plan permutation. It is the work that delays launches and consumes budget without differentiating the product. We generate the first pass with AI tooling, put senior engineers on the architecture and the review, and spend the saved time on the parts customers actually notice. AI accelerates the work. Our engineers stay accountable for the decisions and the software that ships.
An indicative comparison, not a quote or a guarantee. The gain depends on your integrations, pricing model and approval process. We estimate every build individually and put scope, timeline and price in writing, with a like-for-like comparison against conventional delivery, before you commit.
Unit economics
Most SaaS businesses discover their unit economics from an accountant, months late and averaged across everyone. Instrumented properly, you can see it per tenant, in near real time, and price accordingly.
Compute, storage and third-party API spend attributed to the customer that caused it, not spread evenly across the base.
Which tiers are profitable and which are subsidised, so pricing changes are made on evidence rather than instinct.
The one customer generating forty percent of your infrastructure bill, identified before renewal rather than after.
Infrastructure cost modelled against growth, so a funding conversation is not undermined by a surprise cloud bill.
Getting to launch
The first three weeks decide whether the following ten go smoothly, which is why we spend them on foundations rather than features. The exact timeline goes in writing once scope is agreed.
Tenancy model, data model, auth and the billing schema. The decisions that are expensive to reverse, made deliberately and written down.
The features that make the product worth paying for, built on foundations that will not need replacing when the tenth customer arrives.
Billing, trials, self-serve onboarding and the admin surfaces, running in parallel with core product work.
SSO, SCIM, audit logs and security documentation, added when your pipeline needs them rather than speculatively.
Questions we get asked
For most B2B products, bridged: one application with a database per tenant. It gives you a credible answer in security questionnaires, per-customer backup and restore, and a straightforward path to full isolation for the one customer who eventually demands it. Pooled makes sense for high-volume, lower-price products. Siloed is usually a premium tier rather than a default. We will make the recommendation against your sales motion, not a preference.
Yes. We start by characterising what exists with tests, then work in slices behind feature flags. Typical rescue work is separating tenants that were never properly isolated, replacing billing that cannot express current pricing, and adding the enterprise features blocking deals. None of that requires stopping the product.
We integrate with Stripe or your provider of choice and keep the metering, rating and entitlement logic in your own system. That matters because your provider knows what you charged but not what your product actually did, and reconciling those two is where revenue quietly leaks.
Before the deal that needs them, but not years early. In practice, once enterprise prospects are appearing in your pipeline, because security review is where those deals stall. Built on a sound auth model it is a few weeks of work. Retrofitted onto a consumer-style login it is considerably more.
Per-tenant rate limits and quotas, resource isolation appropriate to the tenancy model, and tenant-aware tracing so you can identify the source of a problem in minutes rather than by elimination. Noisy neighbours are a design problem, not an operational surprise.
Often. We can take a defined workstream while your team continues on the product, or embed senior engineers alongside them. In either case the code, conventions and documentation are yours and are written to be picked up by your people rather than to make us necessary.
For a focused product, typically twelve to sixteen weeks from a signed engagement to something you can put in front of paying customers, with billing and onboarding working. We confirm the timeline in writing once the scope is agreed. The foundations phase in the first three weeks is what determines whether the following ten go smoothly.
Two platforms. Open Lance is a live, escrow-protected freelance marketplace, and BotUp is an AI marketplace in controlled beta where every run is capped, logged and billed per run. The billing, metering and multi-tenancy advice on this page is what we operate and get paged about ourselves.
Related services
Related case studies
Next step
A senior engineer reads every enquiry and replies within one business day, starting with the tenancy, billing and identity decisions that are hardest to reverse.
Certified, partnered and awarded
1/7
Discuss your project
Seven short questions. About 90 seconds. A senior engineer reads your answers before we reply. No sales sequence, no newsletter. Just a thoughtful response about what comes next.
Start here
Choose the one that comes closest.
The problem
A sentence or two is enough. Tell us what isn’t working today or what you want to make possible.
Where you are today
Choose everything that applies.
Timing
A real deadline changes how we approach the work. If there isn’t one yet, that’s useful to know too.
Scope
A range is enough. It helps us understand the right approach and team for the problem. It does not determine what we charge.
Your team
This helps us understand whether we should lead the engineering, work alongside your team, or advise your existing engineers.
Stay in touch
A senior engineer will read what you’ve shared and respond within one business day.
How would you prefer to continue?
Received
A senior engineer will review what you’ve shared and come back with the most useful next step.