What We Leave Behind When a Project Finishes

Handover is a milestone, not a favour

A handover requested after the final invoice competes with the supplier's next project. So we treat it as a deliverable with payment attached, which changes how thoroughly it gets done.

The acceptance test is straightforward: can a competent developer who has never seen the system deploy it from the documentation alone?

What you receive

1. The code, in your repository, with full history — it has been there since day one
2. Every account and credential in your name, with us as a user you can remove
3. Deployment documentation, tested by someone following it rather than writing it
4. A recorded walkthrough of the architecture and the awkward parts
5. Decision records — what we chose, what we rejected, why
6. The dependency list with licences, which is expensive to reconstruct later

Ownership in writing

Assignment of the intellectual property in the deliverables to you on payment, stated in the contract rather than assumed. In many jurisdictions, copyright in commissioned software can otherwise rest with whoever wrote it.

The test we apply to our own work: if the relationship ended acrimoniously tomorrow, could the client keep operating without our cooperation? If the answer needs a caveat, the handover is not finished.

Making ourselves replaceable is deliberate

It sounds commercially foolish. It is not. Clients stay with suppliers who could be replaced and choose not to be, and those relationships last considerably longer than the ones held together by lock-in.

It also means our quotes have to compete on merit at every renewal, which keeps us honest.

What happens after

A 90-day warranty on defects, then either a maintenance arrangement or nothing, depending on what the system needs. We will tell you honestly if it does not need one.

Either way you have what you need to have someone else maintain it, including us not being the only people who understand it.

Frequently asked questions