Software development
Building the thing, end to end: the design, the code, the tests that decide whether it ships, and the deployment. We break complex work into small pieces that each do something useful on their own, so there is always something working rather than a plan that is nearly finished. Fewer dependencies and fewer moving parts, because the software still has to be alive in three years.
Service design
The operating model for a service: what it is, who owns it, who does the work, and what people can reasonably expect. Service catalogue, roles and responsibilities, the handovers between teams and suppliers, escalation that works at three in the morning, and service levels that mean something because somebody measures them. Written so the people running it recognise their own jobs in it, which is the difference between an operating model and a diagram.
Process optimisation
Taking a process that works and making it cost less to run. We measure it before changing it, because a process everybody complains about is rarely the one costing the most. Then we take steps out rather than adding a system: automation of a bad process is a faster bad process.
Operation review
An honest look at how something runs today and what it is costing, written so that a board can read it and an engineer can check it. Findings with evidence attached, ranked by what they are worth rather than by how easy they are to fix, and a plain recommendation. We say when the answer is to change nothing.
How we work with people
- A short paid piece of work first, so both sides find out what the other is like before anything large is agreed.
- Fixed scope and a fixed price where the work can be described, and a rate where it genuinely cannot.
- Who owns what is settled in writing before the work starts. On something built for you, that is normally you, with the repository in your name from the first day. Where you are using something we run, you own your data and can take it with you whenever you like.
- We say when something is not worth doing, including when that means less work for us.
Start with the problem, not the solution
Tell us what is not working, what is costing too much, or what you are trying to build. We will tell you what we think is worth doing, and what is not.