Product Engineering
An engineering partner for the whole product lifecycle — discovery, architecture, build, and the unglamorous work of keeping it healthy after launch.
Explore this serviceSaaS Development
The architecture your first enterprise deal will interrogate
A SaaS product is easy to start and expensive to correct. Tenancy, permissions, billing and data isolation are decided in the first month and questioned in the first serious security review. We build those foundations properly, then ship the product on top of them.
- Tenancy decided, not drifted into
- Billing that reconciles
- Audit-ready from the start
Most SaaS rewrites are not caused by scale. They are caused by a tenancy model that cannot express what a customer now needs — a user in two organisations, an enterprise wanting SSO and a separate data region, a role that does not fit the three that were hardcoded.
Tenancy and isolation
We decide the isolation model deliberately: shared schema with row-level security, schema-per-tenant, or database-per-tenant, chosen against your actual compliance and scale requirements. Every query is scoped by construction, so a missing filter is a type error rather than a data leak.
Permissions and billing
Roles are resource-and-action based from the start, because 'admin, member, viewer' will not survive your first enterprise conversation. Billing is wired to entitlements and reconciled against the provider, so what a customer pays for and what they can do never drift apart.
- Subscription lifecycle: trials, upgrades, proration, dunning, cancellation
- Audit logging that answers 'who changed this, and when'
- SSO and SCIM as a configuration, not a rebuild
Problems we solve
What this work is for
The situations teams are usually in when they bring us this problem.
Tenancy bolted on late
A tenant id added to tables after launch leaves gaps. One missing filter is a cross-tenant leak and an incident report.
Billing that does not match reality
Entitlements drift from subscriptions, so customers pay for what they cannot use — or use what they never paid for.
Three hardcoded roles
Every enterprise deal asks for a fourth. Resource-action permissions cost little up front and save the rewrite.
No answer to the security questionnaire
Audit trails, isolation and access control get asked about before the contract. Retrofitting them stalls the deal.
Our approach
How the work runs
The same sequence on every engagement, so there are no surprises in week three.
Decide the foundations
Tenancy, isolation, identity, permissions and billing model — written down with their trade-offs before any product feature is built.
Build the platform
Auth, organisations, roles, subscriptions and audit logging as one coherent layer the product sits on.
Ship the product
Features on top of a foundation that already handles who can see what and who is paying for it.
Prepare for scrutiny
The documentation, logging and controls your first enterprise buyer's security review will ask for.
What's included
What you get
Concrete deliverables — all of it yours to keep, run, and hand to another team.
Tenancy architecture
The isolation model chosen against your compliance needs, with scoping enforced by construction.
Identity and access
Authentication, organisations, invitations, and resource-action permissions ready for SSO.
Billing integration
Subscriptions, plans, entitlements, proration and dunning, reconciled against the provider.
Admin and support tooling
Impersonation with an audit trail, plan changes, and the operational tools support needs.
Audit and observability
Who did what, when — plus the metrics and traces to explain a slow tenant.
Technology
What we build it with
Chosen for the problem, not for novelty.
We are not tied to any of these. If your team already runs something that works, we build with it.
- Platform
Auth, tenancy and permissions as one layer, so no feature has to reinvent access control.
- Next.js
- TypeScript
- better-auth
- RBAC
- Data
Row-level security and query-time scoping, so isolation does not depend on every developer remembering.
- PostgreSQL
- Prisma
- Row-level security
- Redis
- Commerce
Entitlements derived from the subscription, reconciled continuously against the billing provider.
- Stripe
- Webhooks
- Idempotency
- Usage metering
Questions
Before you get in touch
The questions that come up in almost every first conversation.
How long to a launchable v1?
Typically three to five months for a product with real tenancy, billing and permissions. Roughly a third of that is the platform layer — and it is the third that determines whether year two is comfortable.
Can you retrofit multi-tenancy?
Yes, and we have done it several times. It is more work than doing it first, and it needs a careful migration with verification, but it is a well-understood exercise rather than a rewrite.
Do we need SSO on day one?
No — but the identity model should be able to accept it without a rewrite. We design for that, then implement SSO when a deal actually requires it.
Tell us what you're building.
Bring the problem, not a spec. We will tell you honestly whether we are the right team and outline a concrete first step — no obligation, no sales theatre.