Software built to be maintained, not just delivered.

Anyone can ship a first version. The work that matters is whether your team can change it six months later without fear — which is a decision made during the build, not after it.

CAP/ — Capabilities

What we build.

ENG/APP

Web applications

Customer-facing products and internal systems, built with frameworks that will still be maintained in three years.

ENG/API

APIs & integrations

Services, webhooks, and the unglamorous integration work between systems that were never designed to speak to each other.

ENG/TOOL

Internal tooling

The admin panels, back-office workflows and operational scripts that a business runs on and nobody budgets for.

ENG/MOD

Legacy modernisation

Incremental replacement of systems that still work and can no longer be changed safely. Strangler pattern, not a rewrite.

HOW/ — How we build

Five commitments.

Your repositories

Code lands in your version control from the first commit, under your review process. There is no separate environment we work in and hand over from, because handover is where context dies.

Boring technology

We choose widely used, well-documented tools over interesting ones. The question is not what is best today — it is what your team, or your next contractor, will be able to hire for and support. That usually rules out the exciting answer.

Tests where they pay

Thorough tests around business logic, money, and anything that is hard to verify by looking. Light coverage of glue code. We are not chasing a coverage percentage, we are trying to make changes safe.

Deployable from day one

The pipeline exists before the feature does. Building for months and integrating at the end is how projects discover their real problems too late to act on them.

Documentation that isn't an afterthought

Architecture decisions with their reasoning, a runbook for the things that break, and a README that gets a new developer running locally. Written as we go, because written at the end means not written.

SMP/ — A working example

Choosing the smaller thing.

We needed invoicing. We deployed the well-regarded open-source platform first — five containers, a database, a cache, a backup sidecar, and a feature set aimed at businesses issuing hundreds of invoices a month.

For a handful of export invoices a year, that ratio was wrong. We decommissioned it and built a single-container replacement in a day: PDF generation, a ledger, sequential numbering that can't leave gaps, and authentication delegated to the reverse proxy rather than hand-rolled.

Read the engagement note →

The general point

Deploy the standard thing first — it is usually right, and it is always the cheapest experiment
Measure it against the real requirement, not the requirement you might have in five years
Be willing to throw it away. Sunk cost is the most expensive thing in software
Delete features that don't hold up. We built cryptographic PDF signing and removed it once we established it was theatre

CTA/ — Engineering work

Describe what you're building.

A few lines about the system, the constraint you're up against, and what 'done' looks like. You'll get honest first thoughts within a business day — including whether this is worth building at all.

Start a conversation →