Before anyone builds your AI application, agree whose it will be

Handover is usually discussed in the last month of a project, when it is too late to change anything that matters. By then the code lives wherever the provider put it, the deployment runs on infrastructure somebody else configured, the prompts sit in a tool your team has never opened, and the only people who understand why the system behaves as it does are about to move to another client.

None of that is malicious. It is simply what happens when ownership is treated as an event at the end rather than a condition from the start.

Why AI applications make it worse

An ordinary application has code and data. An AI application also has prompts, retrieval configuration, evaluation cases, model choices, cost settings and the accumulated knowledge of which awkward cases broke it and why. Much of that lives outside the code, and much of it is never written down unless somebody asks for it.

It also has a dependency that ordinary software rarely has: a model provider whose products change, are retired and are repriced on a schedule you do not control. A system wired directly to one provider’s model has a hidden dependency, and you find out how hidden when that model changes.

What to agree before the work starts

The code is in your repositories from the first commit. Not transferred at the end. If the provider wants to work in its own repository for a while, that is a reason to ask why.

Deployment runs on your infrastructure, with your secrets. API keys, credentials and environments belong to you. A provider holding the keys to production is a provider you cannot leave.

The model sits behind an interface. So that switching provider or model is a change of configuration and evaluation, not a rewrite of the application.

Prompts, retrieval settings and evaluation cases are versioned with the code. They are part of the product. If they live in a provider’s dashboard, they leave with the provider.

Your engineers work alongside from the start. Not reading a summary at the end. The knowledge that matters in an AI system is mostly about why: why this case is in the evaluation set, why this step uses that model. It transfers through working together, not through documentation alone.

The provider’s involvement declines on a written schedule. With the handover terms — what, in which format, by when — agreed while you still have the leverage to negotiate them.

Infographic

Agree these before the first commit

• Your repositoriesThe code is there from day one, not transferred at the end.
• Your infrastructure and secretsCredentials, keys and environments held by you.
• Model behind an interfaceSwitching provider means configuration and evaluation, not a rewrite.
• Prompts versioned with codePrompts, retrieval settings and evaluation cases are part of the product.
• Engineers alongsideYour people working in the project, not reading summaries.
• Written handover scheduleWhat, in which format, by when — agreed while you have leverage.

The questions that reveal a dependency

“If you disappeared tomorrow, what could we not do?” A good provider can answer this precisely, and the honest answer gets shorter as the project goes on.

“What would it take to change the model?” If the answer involves rewriting the application, the dependency is structural.

“Where is the evaluation set, and who can run it?” It is the most valuable artefact in an AI codebase. If only the provider can run it, only the provider can safely change the system.

“Who has production access today?” By name. Every name from outside your organisation should come with a reason and an end date.

What it costs you

Ownership is not free, and pretending otherwise produces a handover that nobody is able to receive. You need engineers with time allocated to the project — not borrowed from other work for whatever hours are left over — and somebody on your side who will be accountable for the system once the provider steps back. That person should be known by name before the contract is signed. If either is missing, it is better to know that before the project starts and plan for it than to discover it at handover.

What a good outcome looks like

Nothing changes on the day the provider leaves. Your team deploys, monitors and modifies the system as it has been doing for weeks. The evaluation set runs in your CI. The model could be swapped next quarter without a project of its own. The provider may come back for the next project, but not because nothing works without it.

In AI-native apps engineering the code is in your repositories from the first commit, deployment is on your infrastructure, the secrets are yours, the model sits behind an interface, and the handover terms are agreed before the work starts. Our involvement declines on a written schedule, because that is the point.