How we work

We start with how the work is done today: what takes the longest, where the same thing gets typed twice, and what it would be worth fixing. It ends in a written plan.

The first phase goes on how the work is done now rather than on how it could be: what takes the longest, where the same thing gets typed twice, and what it would be worth to fix. It ends with something written down — what to build, in what order, and what we would leave out. If that plan says the project is not worth doing, we say so.

Structure and screens are decided together and drawn before anything is built, so what you agree to is something you have looked at rather than something described to you.

Structure and screens are decided together, because a system that cannot be explained on a screen is usually the wrong shape. We draw the parts that carry the most risk and try to pick holes in them first. Nothing goes to build while an unanswered question is still holding it up.

The work goes live in pieces rather than in one release, with tests written alongside it, so you see it working while there is still time to change your mind.

Work goes live in pieces rather than in one release, so you see it running while there is still time to change your mind. Tests and monitoring are written alongside the feature rather than promised for later, and every change travels the same path from commit to deployment.

We host it, watch it and keep it up to date, and you have someone to call who knows the system. You can take it in-house whenever you want to.

Once it is live we host it, watch it and keep it up to date, under a level of cover agreed in advance. Handover is available at any point and is not a parting gift: runbooks, the notes on why things were done the way they were, and time with your own people.