How we work
A method built around being wrong early
Every engagement is an argument about what should exist. The point of the process is to make that argument cheap to lose at the start, when changing direction costs a conversation, rather than expensive to lose at the end.
Delivery
Four stages, each ending in something you can judge
- 01
Framing
We establish what is true before agreeing what to build: the systems in scope, the constraints that are not negotiable, the people who will operate the result, and the outcome that would count as success. It ends in a plan specific enough to cost.
A costed plan, a named architecture, and the risks ranked
- 02
Sprints
Short cycles against working software. You see the real thing at every step — not a mock-up — early enough that changing your mind is still cheap. Scope is reviewed at each boundary rather than defended.
Working software at the end of every cycle
- 03
Production
Deployment, security review, observability and operational handover are part of the build, not a phase that follows it. A system that works only on the machine that built it is not finished.
Running under real load, with monitoring you can read
- 04
Run
Support, evolution and the transfer of ownership to your team: documentation, walkthroughs and the code review habits that let them take it on. A permanent dependency on us is not a successful outcome.
Your team able to change the system without us
Quality
What we hold ourselves to
Tests where they earn their keep
Coverage of the logic that carries risk, not a percentage target. A suite nobody trusts is worse than no suite, because it is still slow.
Review before merge, always
Every change is read by someone other than its author. It is the cheapest defect-finding mechanism in software and the first one teams abandon under pressure.
Decisions written down
Architecture choices are recorded with the alternatives and the reasoning, so a future maintainer inherits the argument rather than just the outcome.
No silent scope
If something is going to take longer or cost more, you hear it when we find out, not at the end. Bad news does not improve with age.
Security
Practices that apply to every engagement
- Least privilege by default: access is granted for a task and a period, not held indefinitely.
- Secrets never live in source control; credentials are rotated on handover as a matter of course.
- Dependencies are pinned and monitored, and upgrades are treated as routine work rather than emergencies.
- Personal data handling is decided in the design phase, because retrofitting it onto a live system is expensive and sometimes impossible.
- Anything we build to run in production is reviewed against the security expectations of your sector, not ours.
Working together
How the engagement actually feels
You have direct access to the people writing the code — no account layer between a question and the person who can answer it. A written update every week covering what moved, what did not, and what is next. A live review at every sprint boundary. And an honest answer when you ask whether something is worth doing, including when it is not.
Weekly
A written update: what moved, what did not, what is next.
Every sprint
A live review against working software, not a status deck.
Always
Direct access to the engineers, in your channel of choice.
Start with framing
Most engagements begin with a short, fixed-scope piece of work that turns the problem into a costed plan. Tell us what you are facing.