We stay after the launch.

What we think

• If we can't run it, we shouldn't have built it

  Knowing we will be the ones getting the 2am alert changes how we write things. It rules out clever code nobody can maintain, and it rules out shipping without monitoring.

• You own everything

  The repository sits in your organisation and the infrastructure in your cloud account, under every engagement model. You can end the arrangement without a migration project — which means we have to stay useful rather than just embedded.

• We say no

  We turn down work that does not fit, and we say which part does not fit. A project taken on out of politeness goes badly for both sides, slowly.

• Small on purpose

  The people you talk to are the people writing the code. There is no account layer, which is why we cannot take on ten projects at once — and why the ones we take get attention.

How it runs

The same five things, every project

1. 01We start by reading what exists, including the parts nobody documented.
2. 02We agree the architecture before writing code, and we write down why.
3. 03You get deployed previews, not status reports.
4. 04Monitoring goes in before launch, not after the first incident.
5. 05After launch we keep updating, watching, and reporting on cost.