What should be in your hands when the project ends

Handover is the last line on every project plan and the first thing that gets compressed when the dates slip. Nobody argues about it at the start, because everyone is friendly at the start. That is exactly why it is worth arguing about then.

I have taken over systems where the previous supplier had done perfectly good work and the client still could not touch any of it, because one login belonged to somebody who had left. The engineering was fine. The ownership was not, and nobody had checked.

The source code, in a place that belongs to you

Not a folder of files sent over on the final day. The code should sit in your own account, with its full history, from the first week of the project rather than the last. The history matters more than people expect. It is the only record of why something was built the way it was, and the first thing a new engineer looks for.

Ask for access in week one. A supplier who is comfortable with that on day one is telling you something, and so is one who is not.

The trained model, not permission to use it

If part of what you bought was a model trained on your own examples, you should hold the result of that training as a file, along with the data it learned from and the date it was made. Anything less and you are renting back the value of your own records from the people you paid to process them.

The same goes for the written instructions that make the system behave the way it does. A few pages of ordinary text, worth as much as the code, and the part most likely to be sitting in somebody's private notes.

The examples you tested it against

Real cases from your records where the right answer has already been agreed, plus the code that scores a system against them. You should own both, handed over as a working thing rather than described in a report.

This is the item people are most willing to give up and the one that holds its value longest. When somebody proposes replacing the system in a year, that set is how you find out whether the replacement is better or only newer.

Instructions written for an ordinary Tuesday

Not a document about how the system is designed. Instructions for the things somebody will actually have to do: put a change live, restart it, understand the alarm that has just gone off, add a user, remove a user, and what to do when it stops at two in the morning.

There is a test for this. Give the document to somebody who was not on the project and ask them to carry out one routine task from it alone. Whatever they get stuck on was written from memory by somebody who already knew the answer.

Every account in your company's name

This is the one that catches people out, and it is barely technical. A system these days is assembled out of accounts: the place the software runs, the domain name, the certificate that makes the address work, the AI provider, whatever sends your messages, the maps, the payments. Each of those is a login, an email address that controls it, and usually a card being charged every month.

If any of them is registered to your supplier's email address, you do not own that part of your system. You have permission to use it, and permission gets withdrawn, or simply lost when somebody changes job.

• Where the software runs, whether that is a cloud account or your own servers
• The domain name, and whatever renews it
• The AI or model provider, with its own spending limit and its own bill
• Anything that sends messages on your behalf by email, text or WhatsApp
• Any paid component or licence inside the system, with its renewal date
• The place the code lives, and the tool that puts new versions live

For each line, write down whose name it is in, which email address can reset the password, and who is paying. An afternoon of work, and most of the time it turns up at least one entry belonging to an individual rather than to the company.

What it costs to keep running, on one page

Hosting, the amount you pay every time the system answers a question, licences, the domain and certificates, the monitoring, and an honest estimate of the hours your own people will spend on it. One page, with a monthly number at the bottom.

If nobody can produce that page, nobody is watching it, and the first person to find out will be whoever opens the card statement in the third month.

Put all six in the contract, itemised, and make handover something that happens as you go rather than on the last day. Access to the code in week one. Accounts opened in your name when they are created, because moving one across afterwards is a job somebody has to be paid for and it always slips.

If you are already halfway through a project, write the six items down and ask your supplier to point at each one. The conversation takes an hour and is far easier while everyone is still getting on. Send me the answers if you want an opinion on what is missing.