Code, repositories and handover

Ownership

Your code and your intellectual property are yours. Work built on your budget belongs to you, and the assignment is written into the agreement rather than assumed. This is settled in the contract before any work starts, not negotiated at the end.

Where the work lives

In your repository, on your infrastructure, under your organisation's account, from day one. There is no interim period where the work sits somewhere you cannot see it, and there is no handover event where a pile of code moves from my machine to yours, because it was never on only my machine.

If you do not have a repository yet, setting one up is the first commit of the engagement.

How changes land

Through the same review path your team already uses. If you use pull requests, the work arrives as pull requests you can read, comment on and reject. If your team works trunk-based, the work is trunk-based. The point is that you can see each change as a change, with a reason attached, rather than receiving a large diff at the end of a month.

Commit messages explain why rather than restating what, because the diff already says what.

Access during the engagement

Least-privilege and time-boxed: the narrowest grant that lets the work happen, read-only wherever the work allows, revoked when the engagement wraps. Login details never land in a repository or a chat message. The full statement is on Security practices, which is the authoritative version.

Documentation as a deliverable

Every engagement leaves written material behind, and it is not an afterthought:

• Architecture decisions worth knowing in six months, recorded where the code lives rather than in a chat thread.
• A code style and conventions document, so the next person writes code that matches.
• An anti-patterns document, the explicit list of things not to do in this codebase, which is the half most projects skip and then relearn painfully.
• Setup and deploy steps that someone else can actually follow.

For engagements that involve AI coding tooling, that also means the instruction file the tooling reads, so your team keeps the setup after I stop using it.

Ending an engagement

There is no exit fee and no lock-in mechanism. What ending looks like:

1. Work in flight is either finished or written up as unfinished, with the state it is in and what remains.
2. Access is revoked from my side, and you revoke it from yours. Both, not either.
3. The documentation above is current as of the last day.
4. A short written handover: what was built, what was deliberately not built and why, and the known sharp edges.

The test I hold this to is simple: a competent engineer who has never spoken to me should be able to pick the work up from what is written down.