Engineering
Handover is the deliverable
Most agencies treat handover as the last meeting. We treat it as the thing we are building from day one, because code is only worth what the next team can do with it.
There is a familiar ending to agency projects. The agency ships, sends a final invoice, and leaves. The in-house team inherits a codebase that only the agency understood, and within a quarter the system nobody wants to touch is the thing blocking every release.
The bus factor was one all along. It was just an agency instead of a person.
We think handover is not the last step of a project. It is the deliverable, and it gets built from the first commit.
The test
The standard we hold ourselves to is simple to say and hard to fake:
A competent engineer who has never spoken to us should be able to ship a change in their first week, using only what is in the repository.
Everything below exists to pass that test.
The README runs
Clone, one command to set up, one to run the tests, one to deploy. If a step needs a message on Slack to someone who worked on the project, it is a bug, and we fix it like one.
Decisions are written down
Code shows what was built. It rarely shows why. We keep short decision records next to the code: what we chose, what we rejected, and the reason. The next team will disagree with some of them. That is fine, as long as they can see what they are disagreeing with.
You can see the system without us
Logs, error tracking and metrics are set up in week one, in accounts you own, and they are readable by someone who didn't write the code. When something breaks at 3am, the question "what happened?" should have an answer that does not depend on our timezone.
Boring on purpose
We pick tools for the problem, not for the resume. Mainstream frameworks, conventional structure, no clever abstractions that only pay off for their author. If your team already runs something that works, we use that.
Boring code is the kindest thing you can hand to a team that has to live with it.
Everything is in your name
Repositories, cloud accounts, domains, app store listings, analytics: owned by you from day one, with us invited in. You should never need our permission to keep running your own product.
After the handover
We stay on retainer when you want us, and get out of the way when you don't. Both are good outcomes. The one we work to avoid is the one where you need us because nobody else can read the code.
If you are inheriting a system like that right now, tell us what's in the way.