The test we hold ourselves to
A year after we leave, can your team change what we built without calling us? If not, the engagement failed, regardless of what shipped.
That sounds obvious. It is also the opposite of how consultancy revenue usually works, which is why it has to be written into the contract rather than hoped for.
What makes handover fail
- Nobody from the client was in the code. Reviewing pull requests is the cheapest training there is, and the easiest thing to skip when deadlines bite.
- Documentation written at the end. Reconstructed from memory, in a hurry, by someone already on the next project.
- A proprietary layer in the middle. Even a small one makes the client dependent by construction.
- No budget for training. It was in the proposal, and it was the first thing cut.
What we do instead
Everything lives in the client’s repository and cloud account from the first commit. Their engineers review our pull requests, and we review theirs. Runbooks are written during the work, by whoever did it.
The last two weeks of every engagement are training, scoped at the start so they cannot quietly disappear.
Our last invoice should be the one where your team stops needing us.
Why we work this way
Partly conviction, partly evidence. Ninety-one percent of our clients come back, and they come back for new problems rather than to keep the old thing running. Teams that own their platform find more worth building.
Ray Novak
Co-founder & Chair