Service 03 — Web applications

Software that still works
in year three.

Most internal platforms are built for the org chart that exists on the day they launch. Then the data grows, a department splits, an enterprise customer demands SSO, and the thing becomes a maintenance tax. We build for the version of your business that has not happened yet.

Multi-tenant by default SSO, SAML & SCIM Immutable audit log API-first
Discuss your platform What we build
What we build

Platforms that carry real operations.

Not prototypes. Systems that a hundred people log into every morning and that finance closes the books against.

A/01

Multi-tenant SaaS

One codebase, one deployment, isolated data per customer at the row level. Onboarding a new tenant becomes a form rather than a project, and a release ships to everyone at once instead of forty environments in sequence.

Row-level isolationSelf-serve onboarding
A/02

Internal operations tools

The system your ops team currently runs on eleven linked spreadsheets. Approvals, assignment, status tracking and exception handling in one place, with the business rules configurable rather than buried in a formula nobody dares change.

Workflow engineConfig over code
A/03

Partner & vendor portals

External parties working inside your process without touching your internal systems. Scoped access, document exchange, status visibility and a clear boundary between what they can see and what they cannot.

Scoped accessDocument exchange
A/04

Dashboards & reporting

Numbers your board can act on, generated from the source system rather than a spreadsheet someone maintains. Scheduled distribution, drill-down to the transaction, and a definition of each metric visible next to it.

Drill-downScheduled reports
A/05

API platforms

When your data is the product. Versioned REST or GraphQL APIs with authentication, rate limiting, usage metering and documentation your customers' developers can integrate against without a support call.

VersionedMetered
A/06

Legacy modernisation

Taking a working but ageing application forward without a rewrite you cannot afford. We strangle it module by module, moving traffic gradually, so the business keeps running while the old system shrinks.

IncrementalNo big bang
Enterprise readiness

The five things security review asks for.

If you sell to enterprises, deals die at the security questionnaire. These are the items that block them most often — built in from the first sprint, not retrofitted when a deal is on the line.

Adding SSO after launch costs four times what it costs to design for it.

SSO, SAML and SCIM

Your customer's IT team wants their identity provider to control who has access — and wants a leaver removed automatically, not by emailing you. SAML for login, SCIM for provisioning and de-provisioning, tested against Okta, Entra ID and Google Workspace.

Blocks the most deals when missing

Roles their admins control

Three fixed roles will not survive contact with an enterprise customer. We build a permission model down to the action, with a role editor their own administrators operate — so changing who can approve a payment does not become a support ticket to you.

Self-served, not support-served

An audit log they can export

Every state change appended with actor, timestamp and origin, never overwritten. Exportable to their SIEM. This is the question that follows SSO on almost every questionnaire, and "we log to the application console" is not an answer that passes.

Immutable and exportable

Tenant isolation they can verify

Row-level security enforced at the database, not by a filter in application code that a future developer might forget. It is the difference between an isolation model you can demonstrate under questioning and one you have to promise.

Enforced at the data layer

Data residency by region

A UK or EU customer will ask where their data sits, and increasingly so will one in India or Australia. We design for regional deployment from the start so serving a new market is a configuration exercise rather than an architecture project.

Region as configuration
Stack & timeline

Chosen for who maintains it.

If your team is a .NET shop, we do not hand you a Go service to look after. The stack decision follows the handover plan.

LayerWhat we typically useChosen when
Frontend React or Next.js with TypeScript. Server rendering where SEO or first-load speed matters. Almost always — the hiring pool is deepest here.
Backend Node.js, Python, .NET, Java or Go depending on your existing estate and team. Matched to whoever inherits it after handover.
Database PostgreSQL for transactional work, with row-level security for tenant isolation. Default unless you have a standing reason otherwise.
Infrastructure AWS, Azure or GCP in your own accounts. Containers, infrastructure as code, staged deployments. Your cloud, your billing, your access controls.
10–16
Weeks to first release

A usable slice in production, not a full feature set.

2
Week sprint cadence

Demo at the end of each. You see it working, not a status slide.

4–9
People in the pod

Named in the contract. Changes need your agreement.

Proof

Rebuilt for enterprise buyers, then handed over.

B2B SaaS · Multi-tenant platform 🇸🇬 Singapore · 11 months · Under NDA

Forty single-tenant environments consolidated into one

The problem

A growing platform kept losing enterprise deals at security review — no SSO, no granular roles, no audit log. Worse, each customer had their own database and deployment, so every release was a manual exercise repeated forty times over three days.

What we did

Moved to a shared multi-tenant model with row-level isolation enforced in PostgreSQL, added SAML and SCIM, built a role editor their customers' own admins operate, and put an immutable audit log behind every state change. The final two months were spent pairing with their engineers so they owned it before we left.

40 → 1
Environments per release
3
Enterprise deals unblocked
100%
Owned in-house after handover
Before you call

Common questions.

Ask something else

Yes, and about one in six of our application engagements starts this way. We begin with a two-week code and architecture review that tells you honestly what is salvageable. Sometimes the answer is that the data model is sound and the problem is delivery. Sometimes it is that restarting costs less than untangling — and we will show you the reasoning either way.

Probably yes, because five becomes forty faster than the retrofit gets cheaper. The cost difference at design time is small; the cost of converting later is a rewrite of your data access layer. That said, if your customers genuinely require physically separate databases for regulatory reasons, we design for that instead and say so.

With a change request that carries a cost and a schedule impact, brought to you before anything is built. Requirements always move on application work — the failure mode is not the change, it is discovering three months later that scope grew quietly and the date slipped. A dedicated pod model exists precisely for roadmaps that are still forming.

Architecture documentation, decision records explaining why things are the way they are, runbooks for the common operational tasks, and two to four weeks of your engineers pairing with ours on live work. The code has been in your repository since the first commit, so there is no transfer event — just a point where we stop being the ones committing.

Next step

Bring us the
spreadsheet you are outgrowing.

Forty-five minutes with an architect. Show us the process, the workarounds and the last security questionnaire you struggled with. You will leave with a rough scope and a budget band.

Book a discovery call Lending platform instead?