Who this is for
Three kinds of organisation come to us for SaaS work. Founders with a validated problem and no engineering team, who need a first version that can carry paying customers without being thrown away in year two. Established companies productising something they already run internally, which is a different job: the software exists, but it assumes one customer everywhere. And enterprises whose buyers now demand a hosted product where a licensed install used to be acceptable.
The engineering questions differ in emphasis but not in kind. All three meet the same wall eventually. It arrives as the first customer whose security team sends a questionnaire.
Multi-tenancy is the decision you cannot cheaply reverse
How tenant data is separated determines your database schema, your deployment model, your backup and restore procedure, and what you are able to say in a due-diligence call. It is close to irreversible once you have live customers, and it is the decision most often made by default.
Shared schema with a tenant discriminator is cheapest to operate and hardest to defend in an enterprise security review. Schema per tenant sits in the middle. Database or infrastructure per tenant satisfies the review and complicates every migration you will run for the life of the product. None of these is universally correct. The wrong move is arriving at one by accident and discovering the constraint when a regulated buyer asks where their data physically lives.
We make that choice explicitly against the customers you intend to sell to, and we write down the reasoning with the options that were rejected, so the team maintaining it in three years understands why.
From an MVP to something an enterprise will buy
An MVP is a commercial instrument, not a small version of the product. Its job is to answer a question you cannot answer by asking people. That means the scope should be set by the question, and everything not serving it should be visibly deferred instead of quietly dropped.
The parts we argue against cutting are the ones that are cheap now and structural later: tenant isolation, an authentication model that can accept single sign-on when a buyer requires it, and an audit log. Retrofitting any of the three into a live product with customers on it is a migration, not a feature.
Scalability is rarely what kills an early SaaS product. Operability is. A platform nobody on your team can provision, debug or support without an engineer costs more in attention than it ever does in servers.
The backend, the API surface and the integrations you will be asked for
The API is the part of a SaaS product with the longest memory. Once a customer integrates against it you cannot change it casually, so it is worth deciding early what it represents, how it is versioned, and how a breaking change is communicated. Building the endpoints is the easy half. Deciding what they promise is the other one.
Billing logic belongs close to the feature it governs. A plan limit enforced in a separate billing service drifts out of sync with the feature it is supposed to cap, and the drift is discovered by a customer. Usage-based and seat-based models in particular need metering at the point the value is delivered.
Integrations are where roadmaps go to die if they are handled one customer at a time. We build them against a defined extension surface, so the tenth integration is configuration and not a code branch with a customer name in it.
Cloud infrastructure, security and the questionnaire
At some point a buyer will send a security questionnaire, and the answers are set by decisions you made much earlier. Where data is stored and in which jurisdiction. Whether tenants can reach each other. Who on your team can read customer data and what record exists of it. How you would prove any of that after an incident.
We design the infrastructure so those answers exist: environment separation, least-privilege access with the access itself logged, encryption in transit and at rest, dependency and patch management, and backups that have been restored rather than merely configured. Where data residency is a hard requirement, it constrains the hosting choice, and discovering that after selecting a managed service means a rebuild instead of a configuration change.
For clients in regulated sectors this connects directly to our AML/CFT and healthcare engineering work, because a SaaS product serving banks or clinics inherits the obligations of the institutions using it.
Interface work, judged by the support queue
SaaS interface design has a measurable test that marketing sites do not: the volume and shape of your support tickets. Screens people misuse are a design problem showing up as a staffing cost, and the admin side is where this bites hardest because it is the part first builds routinely underinvest in.
We treat tenant provisioning, support access and usage visibility as first-class product surfaces. A platform where every customer question becomes an engineering escalation does not scale, whatever the infrastructure does.
After launch, and modernising a product that already exists
A SaaS platform is a running commitment. Dependencies age, the payment processor changes an API, a browser deprecates something, and a customer needs a feature the schema did not anticipate. Budget for that as ongoing ownership and it is manageable. Treat it as an unplanned interruption and it becomes the reason releases stop.
Where a single-tenant application already exists and needs to become a product, the work is usually larger than it first appears, because the data model assumes one customer in more places than anyone remembers. We scope that after reading the schema, not before, and the honest recommendation is sometimes an incremental extraction instead of a rewrite.
What is included
- SaaS product architecture and multi-tenant data isolation design
- SaaS MVP definition and delivery
- Subscription, usage-based and seat-based billing logic
- Backend and API development, versioning and documentation
- Third-party integrations against a defined extension surface
- Cloud infrastructure, environment separation and deployment automation
- Security architecture and enterprise security questionnaire readiness
- Tenant provisioning, support and usage-monitoring tooling
- SaaS interface design for the product and the admin surface
- Single-tenant to multi-tenant modernisation
- Ongoing maintenance, dependency patching and change delivery
Technologies and standards
Related case studies
- Manufacturing ERP Where Scheduling Was the Competitive Edge: Packaged software for the commodity back office, custom engineering for the scheduling logic that differentiated the business, connected by a deliberate API layer.
- CRM With ML Lead Scoring Kept Off the Decision Path: Machine learning applied where being right most of the time is valuable and being wrong is recoverable: prioritisation, not adjudication.
Further reading
Where this sits in our work
SaaS products sold into regulated buyers inherit their obligations, which we cover under the industries we work in. Where a requirement is already solved, it may be cheaper to configure one of our existing platforms.