SaaS Products
From a prototype that works to a product that holds.
Multi-tenant architecture, role-based access, billing and the unglamorous parts that decide whether an MVP survives its first real customers.
The problem
An MVP is built to answer one question: will anyone want this. The architecture that answers it fastest is almost never the architecture that survives the answer being yes.
The failure is rarely dramatic. It is a second customer whose data must not touch the first one's, a pricing change the billing model cannot express, an admin who needs a permission that does not exist.
This is probably you if
- Your first enterprise prospect is asking questions your architecture cannot answer
- Adding a customer requires a developer
- Pricing is hard to change because it is spread across the codebase
- You are spending more time on support than on the product
What we build
Multi-tenant architecture
Real isolation between customers, in the data model rather than in query discipline. We run this in our own product, so the failure modes are not theoretical.
Roles, permissions and admin
The surfaces your own team needs to operate the product without a developer, and the permission model your customers will ask about during procurement.
Billing and plans
Pricing expressed as configuration rather than as code, so a commercial decision does not become an engineering project.
Analytics and instrumentation
Product analytics wired in from the start, because retrospective instrumentation always measures the wrong thing.
Typical engagements
- Taking a validated MVP to something an enterprise buyer will accept
- Adding white-label or reseller capability to an existing product
- Rebuilding a single-tenant tool as a real multi-tenant platform
- Adding usage-based or credit-based billing to a flat-rate product
Industries we do this in
- Technology
- Healthcare
- Professional services
- Marketing
Questions we get
- Do we have to rebuild from scratch?
- Often not. Usually a specific layer needs replacing, most commonly tenancy or billing, and the rest can be carried forward. We will tell you which after looking.
- Can you work alongside our existing developers?
- Yes. That is frequently the better arrangement, since they hold the domain knowledge and we bring the production architecture.
- What does white-label actually require?
- More than a logo swap. It means supplier names suppressed in the interface, in logs and in error messages, which is a build decision rather than an editorial one.
Tell us what is slowing you down.
A short call, no deck. If we are not the right people for it we will say so and point you at who is.