Pick the shape of the engagement.
A core team of three does all three. What changes is who holds the plan, and the person who scopes your work is the person who writes it.
Turnkey projects
You bring the outcome. We bring the plan, the system and the handover.
Discovery
Two weeks. We read your data, talk to your people, and write the estimate.
Build
Two-week iterations, a demo at the end of each one, trunk-based.
Handover
Runbooks, dashboards, and a fortnight of paired support.
Embedded delivery
We join your team and drive the work, rather than filling a seat. The gap is usually platform, architecture or process, not a shortage of hands.
Match
We tell you who by name, what they last shipped, and which gap they are there to close.
Drive
Planning, architecture and the calls that come with them, alongside your own engineers. On one engagement that has meant running product development across the client’s whole product set.
Flex
Two weeks' notice in either direction. No minimum term after month three.
Long-term retainer
Reserved capacity for systems that must not go quiet.
Reserve
A fixed number of engineer-days each month, the same faces every quarter.
Operate
Maintenance windows, dependency upgrades, incident response.
Evolve
Whatever days are left go to the roadmap, not to firefighting.
Four kinds of work, one team
The engagement model above decides who holds the plan. This is the work itself, and it is the same work whichever shape you pick.
Backend and data
Services, schemas and the parts that have to be right. Java and Grails on systems old enough to have opinions, Python and Go on the ones we start ourselves.
Platform and infrastructure
Kubernetes on bare metal and on VMs, for our own estate and for clients. Terraform for what it provisions, GitLab CI for what it ships, GitOps so the cluster matches a repo rather than a memory.
Architecture and planning
Where the system is going, what it will cost and why. Decisions written down while they are still decisions, rather than reconstructed from the code a year later.
Custom tooling and process
When the work needs something that does not exist yet, we build it. It is why a team this size can take on systems this large, and why the headcount below is not a typo.
Small on purpose
Two of us have been writing production code since the mid-nineties. The third is mid-career. That is the entire core team, and it is a decision rather than a stage we are passing through.
It stays that size because we would rather build the tool than hire the headcount. A lending platform with 631 controllers and no tests at all could have absorbed a year of manual test-writing. Instead we built something that reads the source, works out what the application claims to do, and checks the running system against it. It covers 73 pages and 1,494 form inputs in about three minutes, and it still runs.
Our own delivery pipeline works on the same principle. Agents do a great deal of the labour now, and none of their output counts as finished because they say it is. A unit of work is done when a branch exists on the remote and a check exits zero. Anything else is a claim, and we treat a confident agent exactly like a confident contractor.
When a project needs a specialism we do not hold, we bring in someone we have worked with directly, by name. Never a CV forwarded by an agency, and never a pool of people we have not met.
Non-negotiables
Code you own
Every line, every repo, from day one.
Written decisions
An ADR for anything we'd have to explain twice.
Tests that run
CI green before a demo, not after.
One contact
A team lead who writes code, not slides.
Tell us what the system has to do.
We reply within one business day.