01
SHARED SCHEMA
Tenant column on every table
- OPERATING COST
- LOW
- ISOLATION
- WEAK
Fastest to build. Becomes an obstacle the first time a large customer asks where their data physically resides.
CAPABILITIES / PLATFORM & SAAS
PLATFORM & SAAS.
Multi-tenant platforms, APIs and web systems designed around tenant isolation, data boundaries and the operational cost of scale rather than the launch feature set.
- DISCIPLINE
- 04 of 06
- PRIMARY STACK
- TypeScript · Next.js · PostgreSQL
- TYPICAL FIRST RELEASE
- 5–9 months
- USUAL MODEL
- Dedicated team
Answer
NextSense builds multi-tenant platforms, APIs and web systems for organisations whose product is delivered as software. We design around tenant isolation, data boundaries and the operational cost of scale rather than the launch feature set, working primarily in TypeScript, React and Next.js.
02 / THE PROBLEM
MULTI-TENANCY ISDECIDED ONCE.
Nearly every difficult problem in a mature SaaS business traces back to a decision made in the first month about how tenants are separated. Shared schema with a tenant column is fast to build and becomes an obstacle the first time a large customer asks where their data physically resides.
Full isolation per tenant is straightforward to explain to a security reviewer and expensive to operate at a thousand customers. The decision cannot easily be revisited, because it reaches into every query, every migration, every backup and every piece of access control.
We treat it as the first architectural decision rather than an implementation detail, and we make it against the customers you expect to have in three years rather than the ones you have now.
03 / Situations
WHEN ORGANISATIONS BRING US IN.
An enterprise deal has surfaced requirements the platform cannot meet
SSO, data residency, audit logging, role granularity or a security questionnaire the current architecture cannot answer honestly. The deal has a date attached, and the work needed is architectural rather than cosmetic.
The platform is slowing under its own data
Queries that were fast at ten thousand rows are not fast at ten million, and adding indexes has stopped helping. This is usually a data modelling problem that surfaced late rather than an infrastructure problem.
A monolith needs to be separated, or a set of services needs to be recombined
Either direction is common and both are frequently done for the wrong reasons. We start by identifying where the actual coupling is, which is rarely where the org chart suggests.
04 / THE DECISION
THREE ISOLATION MODELS.
The choice reaches into every query, every migration, every backup and every piece of access control. It is made once, in the first month, and it is the decision enterprise customers ask about first.
02
SCHEMA PER TENANT
One database, isolated schemas
- OPERATING COST
- MEDIUM
- ISOLATION
- MODERATE
A workable middle. Migration effort scales with tenant count, and connection pooling gets harder past a few hundred.
03
DATABASE PER TENANT
Full physical separation
- OPERATING COST
- HIGH
- ISOLATION
- STRONG
Trivial to explain to a security reviewer. Expensive to operate at a thousand customers, and backup strategy becomes a product.
WE DECIDE THIS AGAINST THE CUSTOMERS YOU EXPECT IN THREE YEARS — NOT THE ONES YOU HAVE NOW
05 / How we approach it
Four decisions that reach into everything else
01
Choose the isolation model against your future buyer
If enterprise customers are in the plan, their security review is a design input now. Data residency, tenant separation, audit trails and role granularity are all easier to build than to retrofit.
02
Design the API as the product’s contract
Versioning, error semantics, pagination, idempotency and rate limiting decided at the outset. APIs are the hardest part of a platform to change once anything depends on them.
03
Make the system observable before it is large
Structured logging, tracing and meaningful metrics from the beginning. Diagnosing a production problem in a system not built to be observed is where operational cost quietly accumulates.
04
Treat performance as an architecture question
Query patterns, caching boundaries and background work designed against expected data shapes. Most performance problems in SaaS platforms are data modelling problems that surfaced late.
06 / What we build
SIX KINDS OF PLATFORM.
Multi-tenant SaaS platforms
From first version through the architecture changes that enterprise customers force.
APIs and integration layers
Public and partner APIs, webhooks, and connections into systems never designed to be connected to.
Customer-facing web applications
Performance-sensitive interfaces where speed and accessibility are commercial rather than technical concerns.
Commerce systems
Catalogue, checkout, payment and fulfilment, including cross-border tax and currency handling.
Internal platforms and admin
The operational tooling that determines how expensive a product is to run.
Re-architecture
Migrating platforms that have outgrown their original design without stopping delivery.
07 / Technical depth
SPECIFICATION.
- FRONTEND
- TypeScript, React, Next.js App Router. Server components by default, static and incremental generation where content allows, and a hard budget on client-side JavaScript.
- BACKEND
- Node and TypeScript, Python where the workload favours it. Service boundaries drawn along ownership rather than along technical layers.
- DATA
- PostgreSQL as the default. Tenant isolation strategy, migration discipline on live systems, indexing against real query patterns, and read replica strategy where load justifies it.
- ACCESS CONTROL
- Role and attribute-based permissions, SSO and SAML for enterprise, API key and token lifecycle, and audit logging designed to satisfy a reviewer rather than a developer.
- OPERATIONS
- Containerised deployment, infrastructure as code, staged environments, structured logging, distributed tracing, and alerting on user-visible symptoms rather than machine metrics.
- PERFORMANCE
- Caching layers and invalidation strategy, background job architecture, and Core Web Vitals treated as a product requirement.
08 / THE TRUST SECTION
WHEN BUILDING THE PLATFORM ISN’T THE ANSWER.
Not every product needs to be built, and not every architecture needs to change.
If an off-the-shelf platform covers eighty per cent of the requirement, the honest question is whether the remaining twenty is worth a build and a maintenance commitment that lasts as long as the business does. Frequently it is better addressed by configuration, an integration, or accepting a different workflow.
If the pressure is to move to microservices, the question we ask is what problem the split solves. Independent deployment and independent scaling are real benefits. Neither is achieved by dividing a codebase that shares one database, and the result is a distributed system with all of the coordination cost and none of the independence.
If the platform is slow, rewriting it usually will not help. Performance problems are typically concentrated in a small number of query patterns, and finding them is cheaper than replacing everything around them.
09 / What you get
WHAT AN ENGAGEMENT PRODUCES.
- 01
A written architecture covering tenant isolation, data model, service boundaries and access control, with the reasoning recorded.
- 02
The platform in the client’s own repositories and cloud accounts, with infrastructure defined as code.
- 03
An API specification with versioning, error semantics and idempotency defined, published for internal and partner use.
- 04
Observability configured — structured logging, tracing, and alerting on user-visible symptoms rather than machine metrics.
- 05
A migration approach for live systems: backward-compatible changes, reversible steps, and no scheduled downtime.
- 06
Documentation covering operational runbooks, access control model, and the security posture an enterprise reviewer will ask about.
10 / Selected work
PROOF.
20K
20,000 users and 3,000 verified creators in the first operational year
A DIGITAL GOODS MARKETPLACE OPERATOR
Next.js · Blockchain integration · Payments
One engagement is documented for this discipline. We would rather show a single well-specified example than place a vague second beside it.
11 / Areas of depth
SAAS PLATFORMSNEXT.JS ENGINEERINGE-COMMERCE
Where this applies
Financial services · Healthcare · Real estate · Logistics & mobility · Sports & media
12 / FAQ
QUESTIONS, ANSWERED.
Rendered open in the DOM. FAQPage schema.
How should tenant data be separated?
Through one of three models: shared schema with tenant scoping, separate schema per tenant, or separate database per tenant. The right choice depends on customer size, regulatory exposure and how many tenants you expect. It is difficult to change later, so we decide it explicitly with the future customer base in mind.
Can you work on an existing platform?
Yes. We generally begin with an assessment covering architecture, data model, dependency health, test coverage and operational maturity, and return a written view on what should be changed, in what order, and what can safely be left alone.
What does enterprise readiness actually require?
Usually SSO and SAML, role-based access control with meaningful granularity, audit logging, data residency options, documented security practice, and a support and incident process. Most of it is cheap to design in and expensive to add under the time pressure of a specific deal.
How do you handle migrations on a live system?
Incrementally, with backward-compatible schema changes, dual-write periods where necessary, and the ability to reverse each step. Migrations that require downtime are usually a sign that the change was designed as a single event rather than a sequence.
Do you build the infrastructure as well?
Yes, as infrastructure as code, in the client’s own cloud account. We do not host client systems on our own infrastructure.
Who owns the code and infrastructure?
The client, from the first commit, including repositories, cloud accounts and third-party service ownership.