Small, senior, and deliberately hard to scale.
We cap the number of projects we take because the thing clients actually buy is attention from people who have built this before. That does not survive being turned into a delivery pipeline.
Most software problems are actually decision problems.
Almost every rescue project we take has the same shape. The code is not incompetent. It is the accumulated residue of a hundred small decisions made quickly, under pressure, by people who were never given the time to consider the second-order effects — and never wrote down why.
Two years later nobody can change the schema safely, the deploy takes forty-five minutes, and a demo that impressed the board falls apart on real data. The fix is rarely more effort. It is a small number of correct structural decisions, made deliberately and documented.
That is what we sell. Not hours, not headcount — judgement about which decisions matter, followed by the engineering discipline to execute them properly and hand them over in a state your team can still work with in two years.
Six rules that shape every engagement.
These are not aspirations on a wall. Each one costs us something in the short term, which is how you know we mean them.
Architecture before code
The expensive mistakes are made in week one, in a decision nobody wrote down. We write them down, with the trade-off and the reason, and you keep that document forever.
Measure, then optimise
We profile before we refactor and build an evaluation set before we tune a prompt. Opinions about performance are cheap; a flame graph settles the argument in an afternoon.
Boring technology, deliberately
We choose tools for operational calm, not novelty. When something newer is genuinely better for your case we will say so, and price the maintenance cost honestly.
Security is not a phase
Authorisation at the API, secrets in a vault, scanning in the pipeline — from the first commit. Retrofitting it after an enterprise deal stalls costs several times more.
Ship weekly, in public
Every Friday there is something in staging you can click. Long silences are where projects quietly go wrong, so we design the cadence to make that impossible.
Leave nothing behind
Runbooks, decision records, onboarding guides, and a walkthrough for whoever inherits it. A system only you can operate is a liability we refuse to hand over.
Who is actually on your project.
The people on the discovery call are the people who write the code. If that ever stops being true, we will tell you before you find out.
Things we will not do
A list of what an agency refuses is usually more informative than a list of what it offers.
- Staff a project with people less experienced than the ones you met.
- Bill for a discovery phase that produces only a slide deck.
- Hold your code, infrastructure, or credentials as leverage.
- Ship an AI feature with no evaluation set behind it.
- Quote a number we already know we cannot hold.
- Take work we are not the right team for, and learn on your budget.
How working with us actually goes.
No discovery phase that bills for six weeks and produces a slide deck. You get a plan with a number attached in the first week, and something running in the second.
- 01
Discovery call
15 minutesYou describe the problem. We ask the four or five questions that determine the approach, and tell you on the call whether this is something we should build.
- 02
Architecture sprint
5 working daysA fixed-fee week that produces the system design, the risk register, a phased plan, and a real number. You own the document either way, and it credits against the build.
- 03
Build in weekly slices
3 to 14 weeksEvery Friday there is something in staging you can click. Types at the boundaries, tests on the paths that matter, and a changelog you can read without us in the room.
- 04
Handover or embed
OngoingArchitecture walkthrough, runbooks, and onboarding docs for whoever inherits it. Or we stay on as your engineering function. Both are fine outcomes.
Tools we reach for
Not a badge collection. This is the set we have run in production long enough to know the failure modes, which is the only reason to prefer one tool over another.
Let us look at your architecture.
Two ways to start, both of them short. Bring the problem, not a specification — the first useful thing we do is tell you what we would build and roughly what it costs.
Book an architecture call
Fifteen minutes, no deck. We map your problem to an approach and tell you what a realistic scope and budget look like.
- A specific technical recommendation
- A budget band you can plan against
- An honest answer if we are the wrong fit
Send a written brief
Prefer to write it down? Email us the shape of the problem and we will reply with a first take, usually under 12 hours.
- Goes straight to an engineer, not a sales inbox
- We reply with an approach, not a brochure
- Attach anything: repos, docs, screenshots