Multi-tenant products, built to survive their second year
Most SaaS products are easy to demo and hard to operate. The parts that decide whether a product is still maintainable eighteen months in — tenancy, roles, billing, background work, audit — are the parts we build first, because retrofitting them is what stalls a product.
Concrete deliverables, not adjectives
- Tenancy and organisation models
- Organisations at the top, teams under them, and a permission model that answers 'who can see this row' in one place rather than in every query. Reach runs this model: an organisation owns its members, its numbers and its credit balance, and usage is attributed back to the person who spent it.
- Metered and credit-based billing
- Usage that has to be counted before it can be charged: per-unit rates, prepaid balances, tiered pricing, top-ups, and the reconciliation job that makes the ledger agree with the provider. Reach prices in credits across seven volume brackets, in two currencies, with tax handled at the billing address.
- Background job pipelines
- The queue is where SaaS products actually fail. Broadcasts, imports, exports and webhooks run as durable jobs with retry policy, dead-letter handling and per-recipient status — not as a request that has to finish before the browser gives up.
- Admin and support tooling
- The screens your own team lives in: account lookup, credit adjustment, delivery investigation, feature toggles. Built early, because support requests answered by a database client do not scale past the first few customers.
The parts a demo doesn't show
- Real-time where it matters
- Socket channels for the things a person is watching happen — delivery receipts landing, an inbox thread updating — and plain polling for everything else. Real-time everywhere is a cost, not a feature.
- Schema you can migrate
- Relational schema under a migration tool, versioned with the code. A product that cannot ship a schema change on a Tuesday is a product that stops changing.
- Idempotent integrations
- Webhook handlers and provider callbacks written to be delivered twice, because they will be. Every external event carries a key, and replaying it changes nothing.
- Observability from day one
- Structured logs keyed by tenant and request, health endpoints, and job-level metrics — so a delivery question has an answer that is not a guess.
The order things actually happen in
Model the tenancy first
Before a screen exists: who owns data, who can see it, what happens when someone leaves an organisation, how usage is attributed. Nearly every expensive rewrite we have seen starts by answering this late.
Build the spine
Auth, organisations, roles, the job queue and the billing ledger — thin but real — so every feature after this lands on finished foundations instead of temporary ones.
Ship feature slices
One capability end to end at a time: schema, API, UI, background work, and the admin view for it. A slice that is not operable is not finished.
Harden before launch
Load-shaped testing on the queue, failure drills on the provider integrations, and a run-book for the first support call. Then deploy.
The stack, and why each piece is in it
- Application services
- Java · Spring Boot · Node.js · TypeScript · ExpressSpring Boot where the domain is heavy and long-lived; Node with TypeScript where the work is I/O-bound and the team wants one language across the stack. Reach's API is the second of these.
- Data
- PostgreSQL · MySQL · MongoDB · DynamoDB · RedisPostgres is the default — a billing ledger wants transactions. MongoDB and DynamoDB appear where the shape is genuinely document- or key-oriented. Redis carries the job queue and the ephemeral state.
- Front end
- React · Next.js · AngularNext.js when the pages need to be indexed and fast on first paint; a plain React SPA when the product lives behind a login and routing is the only server concern.
- Delivery
- Docker · AWS ECS & Fargate · CI/CD pipelinesContainers so the thing that runs in production is the thing that ran on a laptop, and a pipeline that builds, migrates and deploys without anyone opening a console.
See it, don’t take our word for it
NexBroad-Reachis built by this team, on this stack, and it’s running live — open the product instead of a screenshot of it.
Web development
A marketing site and an operations console are not the same problem, and building them the same way is how one of them ends up slow. We pick the rendering model per surface, then hold the line on payload, accessibility and the states nobody demos.
Mobile development
The phone in a warehouse, a van or a ward is not the phone in a demo. We build for intermittent connectivity first: local state that survives, sync that resolves conflicts, and a screen that still tells the truth when the bars run out.
Tell us what you want built
A short brief is enough to start — what you're trying to do, and roughly for whom. We'll tell you honestly whether it's a fit.