What You Should Own When a Build Ends

A build finishes, the thing works, everyone is pleased. Eighteen months later you want to change it, the person who built it has moved on, and you discover that what you bought was access rather than ownership.

This is avoidable and almost nobody avoids it, because the conversation belongs at the start of a project and feels distrustful there.

Ownership is four separate questions

People treat this as one thing. It is four, and you can own some and not others.

The accounts. Every service the system runs on: hosting, database, the AI provider, the email service. Registered to your company email, on your company card, with your company as the account owner. Not to the developer’s account with you as a guest.

The code and configuration. In a repository your company owns, that you can grant and revoke access to. If it lives in the builder’s account, they can end your access unilaterally and no contract clause makes that convenient.

The data. Yours, exportable in a usable format, on demand and without asking. Test this rather than believing it.

The knowledge. The part everybody forgets, and the one that actually determines whether another firm can take over.

The account question is the urgent one

If a build sits on accounts registered to somebody else, everything else is theoretical.

It is not usually malicious. A developer sets up an account quickly to get moving, meaning to transfer it later, and later never comes. Then they change jobs, or you have a disagreement, and your production system is running on credentials belonging to a person who no longer works with you.

Check this today, on anything already running. It takes twenty minutes and it is the single highest return audit in this article.

The handover document nobody writes

Ask for one page per system covering: what it does, what it connects to, what breaks it, and what to do when it breaks.

Not technical documentation. That has its place and it is not this. This is the page a competent person who has never seen the system reads before touching anything, and it is what makes replacing your builder a possibility rather than a rebuild.

The reason it never gets written is that it is genuinely tedious and it is the last thing on a project that everybody wants to close. Ask for it as a deliverable with money attached, not as a favour at the end.

The AI specific parts

Systems with an AI step have three assets that did not exist in ordinary software, and none of them are obvious.

The prompts and instructions. These are the real intellectual property in an AI system. Months of refinement about how your business makes decisions, written down. They should be in your repository, in plain text, and readable by you. If they are embedded in a platform you rent, you are renting your own operating knowledge.

The examples. The cases used to tune behaviour, particularly the corrections. That set is specific to your business and cannot be recreated from scratch. It is worth more than the code around it.

Model portability. Ask directly whether the system can be pointed at a different provider, and what that would take. Model providers change prices and retire versions. A system that can only run on one is a dependency you did not price.

We hand all three over as a matter of course, because a client who cannot leave is not a client who stays for the right reasons.

What the knowledge actually consists of

The fourth item on the list is the vaguest and the one that decides whether any of the others help you.

Somebody who has never seen the system needs to be able to answer four questions from your documentation alone. What happens when this runs. Where does it get its input and where does the output go. What are the known failure cases and what do they look like when they occur. And what did you deliberately decide not to handle, and why.

That last one is the most valuable and the least often recorded. Every build contains decisions to leave something out: a case too rare to be worth it, an integration that was not ready, a rule the business could not agree on. Without that list, the next person treats each of those as a bug, spends two weeks discovering it was intentional, and frequently reverses a decision that was correct.

Test the handover before you sign it off

The cheapest possible verification, and almost nobody does it: while the builder is still engaged, have somebody else attempt a small change using only the documentation and the access you have been given.

Not a real change necessarily. A trivial one. If they cannot get as far as running the system, the handover is incomplete and you have found out while you still have leverage rather than after the relationship ended.

An hour of somebody’s time, and it converts a folder of documents into a tested fact.

What is reasonable to not own

This is not an argument for owning everything, which is expensive and usually unnecessary.

You do not need to own the platforms underneath. Nobody owns their email provider. What you need is that the parts specific to your business, the logic, the data, the configuration and the instructions, sit somewhere you control, on accounts in your name, so that changing supplier is a project rather than a rebuild.

Reusable components a builder brings to every client are theirs, reasonably. Ask for the licence position in writing so it is a known fact rather than a surprise.

The five questions, asked before you sign

• Whose name are the accounts in, and when do they transfer.

• Where does the code live, and can I revoke your access without losing mine.

• Can I export all my data today, in a format something else can read.

• What documentation is a deliverable, and is it in the price.

• If we parted company tomorrow, what would the next firm need, and do they have it.

Asked at the start, these are five minutes of a good supplier’s time and they will have answers ready. Asked at the end, they are a negotiation. Asked eighteen months later, they are a problem.

How a builder reacts to being asked is itself information. The right answer is a shrug and a list.

AI Optimize hands over the accounts, the code, the data and the prompts as standard, in your name, on request. That work sits under Custom Software.