Services · Engineering
Platform Builds
Category
Engineering
Starts with
A scoping call
Status
Booking 2026
(01) Our take
Most of the multi-tenant systems we’ve been hired to fix share the same origin story: they started as a single-tenant product, sold well, and then had multi-tenancy retrofitted under pressure. The retrofit works for a while. Then it doesn’t. The queries get slower, the feature flags get wider, and at some point a customer sees another customer’s data and the engineering team spends six months rebuilding the foundation they should have had on day one.
Platform Builds is the engagement where we do the day-one work properly. The tenant model — shared schema with row-level security, schema-per-tenant, database-per-tenant, or a hybrid — is the most important decision a platform makes, and the right answer depends on data volume, compliance posture, and how differently tenants configure the product. We walk through those trade-offs explicitly with your team rather than defaulting to whatever we used last time.
The permission model matters almost as much. Role-based access is table stakes; we add attribute-based permissions when the product has resources that need conditional access, and relationship-based models (the Zanzibar shape) when users share documents across tenant boundaries. The goal is a permission layer your product engineers can extend without understanding database internals, and a support team that can answer “why can’t this user see this thing” without escalating to engineering.
Above that foundation we build the platform surface — admin consoles, onboarding flows, tenant provisioning, billing integration, and the support tooling your ops team will live in every day. We pair all of it with the internal observability to diagnose tenant-specific problems without touching customer data, and a testing posture that catches cross-tenant leaks before they reach production.
We default to Next.js + Postgres + a Node backend on AWS or Vercel, with Terraform-defined infra from the first provision. For scale beyond typical mid-market, we’ll plan a shard strategy explicitly rather than hoping the database stays under the knee of its curve.
(02) What we build
Typical work
- Greenfield multi-tenant B2B SaaS platforms
- Tenant-model redesigns for single-tenant products that hit the retrofit wall
- Internal platforms for product teams inside larger organisations
- Developer platforms with API keys, usage metering, and self-serve onboarding
- Admin consoles and operational tooling for existing platforms
(03) Is this for you
When to pick this
- You’re building a B2B SaaS product and you know it needs to serve multiple customers from day one.
- You’ve hit the retrofit wall on an existing product and need to redesign the tenant layer without a full rewrite.
- You’re an enterprise product team and need an internal platform that’s as good as the SaaS tools you’d buy.
- You want a partner who’s going to think hard about permissions, data isolation, and observability before writing feature code.
When not to pick this
- You’re pre-MVP and you don’t have customers yet. Ship a single-tenant product, sell it, then come back.
- A multi-tenant CMS or off-the-shelf platform solves 80% of your problem. Don’t build what you could buy.
(04) Engagement shape
How we engage
Greenfield platform builds typically run 16–32 weeks to a first commercial launch, phased through discovery, foundation work, and iterative product delivery. Retrofit engagements are shorter but denser — often 8–16 weeks of concentrated work.
(05) What you walk away with
Deliverable
The headline artefact
A production platform with tenant boundaries, permissions, and operational tooling your team can extend without rebuilding.
Signature tools we reach for
(06) Pairs with
Related services
Services we often run alongside Platform Builds, or that make sense as the next engagement after it.
Start a Platform Builds engagement.