SaaS Product Engineering
SaaS product engineering is building a multi-tenant platform that holds up under real customers — getting tenancy, billing, roles and data isolation right early, so the MVP you launch is the foundation you keep rather than the prototype you throw away. Cordytech takes products from a validated idea to a hardened platform, then keeps hardening as the customer count grows: query performance, queue throughput, rate limiting, and the observability to know which of those is actually hurting. Mailflow, the multi-tenant control plane we build and run, is the reference build.
Multi-tenancy is where most SaaS builds accrue their worst debt, and it is almost always invisible until the second or third real customer. The boundary between tenants either exists in every query from the first migration, or it gets bolted on later at ten times the cost and half the confidence. We make it explicit on day one.
Getting there is less about clever architecture than about refusing to defer the hard decisions. Billing, roles, data isolation, and the migration path are product surfaces, not plumbing you add before launch. Decide them early and the MVP is a foundation; defer them and the MVP is a prototype you will pay to replace.
01What is multi-tenancy, and where does it go wrong?
Multi-tenancy is one application serving many isolated customers from shared infrastructure — where "isolated" is the load-bearing word. It goes wrong the moment a query forgets which tenant it is for. One missing scope on one report, and customer A sees customer B's data; the bug is a headline, not a ticket.
So we make isolation the default rather than a thing each feature has to remember. Every query is tenant-scoped, every background job carries its tenant context, and every new feature inherits the boundary instead of re-inventing it. The safest isolation is the kind a developer cannot forget, because the framework applies it whether they remember or not.
02How do you get tenancy, billing and permissions right from day one?
By treating them as the first features, not the last. Tenancy defines how every other table is keyed, so it comes before the schema settles. Roles and permissions decide who inside a tenant can do what, and they are far cheaper to design in than to retrofit once customers have shaped their teams around their absence.
Billing is the one teams most often postpone and most regret postponing. Usage metering, plan gating, and the upgrade path are product surfaces your customers touch directly, and they leak into the data model in ways that are painful to change later. We wire them in while the model is still soft.
03How do you take a product from MVP to production hardening?
In two phases with a clear line between them. The MVP phase is about finding out whether the product is right; the hardening phase is about making the right product hold up. Same codebase, different questions.
| MVP phase | Hardening phase |
|---|---|
| Ship the core loop to real users | Keep it fast as the customer count climbs |
| Prove the tenancy and permission model | Eliminate N+1 queries and add the missing indexes |
| Get billing and plan gating working | Tune cache strategy and queue throughput |
| Learn what the roadmap actually is | Add rate limiting and back-pressure where it is needed |
| Instrument the basics | Add the observability to know which bottleneck is real |
The line matters because hardening the wrong product is waste, and shipping an unhardened right product is a fire. You want to cross it deliberately, once you know the loop is correct.
04What does the reference build look like?
Mailflow is the platform the rest of our work leans on, and the clearest example of this practice. It is multi-tenant to the core — teams, roles, and per-ISP permissions — with cloud-provider abstractions hidden behind a factory so a new provider is a driver, not a rewrite. Long-running work runs in queues rather than on the request, and a provisioning run streams its log into the browser so a failure names the command that killed it instead of hiding in a black box.
Where PHP was the wrong tool, we reached for the right one: Mailflow's sending engine is a compiled Go binary that talks to the database directly. It was built during our engagement with Mobicentrum and now runs the sending infrastructure at Relentia and EMG. Revline and Storebridge are built to the same shape at a different scale — provider drivers, queued work, partial-failure handling. The pattern travels because it is a discipline, not a framework.
05How do you keep it scaling without a rewrite?
By hardening the things that actually hurt, in the order they hurt. Scaling problems are boringly predictable — the N+1 query that was fine at ten tenants and fatal at a thousand, the cache that was never invalidated, the queue that quietly fell behind — and the trick is measuring which one is biting before you optimise the one that is not.
That is what the observability is for. We instrument the platform so the next bottleneck announces itself with evidence, and we fix it as a targeted change rather than a rebuild. A product that scales with its customer count without a rewrite is not luck; it is the payoff of the decisions made in phase one.
06Questions we get asked
Can you harden a platform someone else built?
Often, yes — the first step is measuring where it actually hurts before touching anything. The N+1 query and the missing tenant scope announce themselves quickly once the platform is instrumented.
Do we need to know our billing model before we start?
You need to know it before you launch, not before you start. We keep the data model soft enough to absorb billing decisions during the MVP phase, and firm once the model is proven.
How does this relate to your other services?
A SaaS platform is custom web application development that grew a tenancy boundary and a billing model, and it usually needs platform integration to reach the systems around it. If you have a validated idea or a straining MVP, tell us where it hurts and we will say which phase you are in.
Ready to scope it?
Tell us the problem and the outcome you want. A real person replies within two business days.