Web applications

What you get

An application your team can operate: roles and permissions, an audit trail, background processing, and notifications by email, push and webhook.

How it works

FRONTEND → API → BACKEND → DATABASE, with authentication, jobs and notifications alongside. Redis carries the cache, the rate-limit counters and the queues; PostgreSQL carries the records; object storage carries the files.

What we measure

Request latency at p95, queue depth and retry rate, error budget burn, and the product events that tell you whether a workflow is actually being completed.

Where web applications usually go wrong

Three things account for most of the trouble we are called in to fix.

Permissions bolted on late. Authentication is easy; authorisation is not. If the rule about who may see a record lives in the component that renders it, then every new screen is a new chance to leak. The rule belongs below the API, in one place, enforced on the way out of the database — and for anything that really matters, enforced by the database itself. A role with no read privilege cannot leak a row through a bug in the code above it. That is application security work, and it belongs in the design rather than in a review at the end.

Work done in the request. Sending the email, generating the PDF and calling the third party all happen while the user waits, until one of them is slow and the page times out. Anything that can fail independently belongs on a queue with a retry policy and somewhere to look when it stops.

No audit trail. The first serious support question is always "who changed this, and when". If the answer requires reading application logs, the answer is effectively no. An append-only record of consequential actions costs almost nothing to write on day one and cannot be reconstructed later.

Build or buy

We will tell you when something off the shelf is the better call. A CRM, a help desk, a payments flow and an identity provider are all solved problems with mature products, and rebuilding one to avoid a monthly fee is usually a bad trade once you count the maintenance.

Custom software earns its cost where the workflow is actually yours — the part of the business that does not look like anyone else's, the integration nobody sells, the process currently held together by a spreadsheet and one person who knows the rules. That is the part worth building.

Operating it afterwards

An application is not finished when it ships; it is finished when someone can run it. That means a deploy anyone on the team can trigger, logs and metrics with somewhere to look when a user reports something odd, a backup with a restore that has been rehearsed, and a dependency update path that does not require a rewrite in two years.

We build those in from the start because retrofitting them means touching every surface again.