We haven't yet had to rescue a client from a poorly delivered AI project. We've seen badly documented systems in other contexts, we know the real cost of inheriting them, and that's why we treat every delivery as if the client would be continuing with another vendor tomorrow, even when that's not the case.
This way of thinking changes how the project is designed from the start. You don't write code thinking "we'll document at the end", you don't leave credentials in personal files, you don't use services that only one person on our team knows how to configure. Every technical decision passes through a simple filter: if tomorrow the client wanted to take this system home, could they?
This article explains why handovers in AI projects are more complex than in other systems, what a well-done delivery should include, and what the warning signs are before signing with any vendor promising "intelligent systems".
Why an AI handover is more complex than others
In a traditional web project, a well-done handover involves documented code, access credentials and a clear README. Most knowledge is in the code: if a new person reads it, they can deduce what the system does and how to maintain it.
In an AI project, that isn't enough. The system's behaviour isn't only in the code: it's in the prompts, in the model configurations, in the connected tools, in the orchestration flows, in the evals that define what a correct response looks like and in the architectural decisions that often only make sense with the context of the specific case. A new team can read the code and understand what each function does, but without additional documentation they won't understand why this prompt, this model or this sequence of actions was chosen.
On top of that, there's another factor: AI systems are living systems, not static. They need periodic evals, adjustments when behaviour drifts, decisions about when to update models. Without proper handover of this operational layer, the system will work the first month and start degrading slowly the second or third, without the client knowing why.
A quality handover must cover all of these layers, not just the code.
The six elements of a well-done handover
Based on our experience building AI systems and the practice of treating every project as if it were deliverable tomorrow, these are the six elements we consider essential in a serious technical delivery:
1. Complete technical documentation. It's not a three-line README. It's a structured collection that includes: system architecture (what exists, what each part does, how they communicate), relevant technical decisions (why this model, why this database, why this orchestration), operational runbooks (what to do when X fails, how to diagnose Y), and diagrams where useful. If a senior engineer can read it and understand the system in an afternoon, it's well done.
2. Full access to credentials and accounts. All accounts, APIs, tokens, repositories and services must belong to the client, not the vendor. It sounds obvious but it's the first point where many handovers fail: the API account is under the vendor's name, the repository is on their personal GitHub, the monitor is on a service the vendor pays for. When the client wants to leave, they have a system but no control over it. A well-done handover reverses this: the client has everything, the vendor only has access while the relationship lasts.
3. Automated tests and evals system. In AI, evals are as important as unit tests in traditional software. They let you validate that the system keeps making correct decisions when someone touches the code, changes a model or adjusts a prompt. Without evals, any modification to the system is an act of faith. A well-done handover includes an eval suite runnable with a single command, test datasets specific to the case, and clear success criteria.
4. In-person or video transfer session. Documentation is necessary but not sufficient. A 2-3 hour session with the client's technical team, where the system is explained, real demonstrations are made and questions are answered, is worth fifty pages of documentation. It's where tacit knowledge is transferred: those things no one writes down but everyone needs to know to operate the system.
5. Post-delivery support period. A system is never delivered "closed". Questions, unexpected behaviours or new needs always appear in the first few months. A well-done handover includes a post-delivery support period —typically between 1 and 3 months— during which the team that built the system remains available for queries. It's not a hidden premium service: it's part of the responsibility of the vendor who built the system.
6. Documented maintenance plan. What needs to be done weekly, monthly, quarterly to keep the system healthy: review evals, check error logs, monitor costs, update critical dependencies. A clear maintenance plan lets the client decide whether to handle it internally or hire maintenance from someone —the same vendor or another. The key is being able to choose with information, not with ignorance.
Warning signs before signing with a vendor
If you're evaluating vendors for an AI project, here are four warning signs that indicate you probably won't receive a decent handover:
Sign 1: the vendor talks only about the demo and not about how it's maintained in production. If in commercial meetings 90% of the time is spent showing how beautiful the system looks running and 10% (or less) explaining how it's operated, measured and maintained, that's a sign their mindset is "deliver and leave", not build something that lasts.
Sign 2: the budget has no line for documentation, transfer or post-delivery support. If the budget only includes development and nothing else, it means the vendor is thinking minimum viable to charge and leave. A serious vendor considers documentation and transfer as integral parts of the project, not as additional services.
Sign 3: they ask you to sign a contract where only they have access to the code or infrastructure. If intellectual property doesn't clearly stay with the client, or if main accounts remain under the vendor's name, they're creating structural dependence from minute zero. A serious vendor insists that everything stays under the client's name from the start.
Sign 4: they offer mandatory monthly maintenance with no option to exit or switch hands. There are vendors who structure contracts so the client stays trapped: only they can maintain the system, only they have access, only they know how it works. This isn't a commercial relationship, it's a technical mortgage. A serious vendor offers maintenance as one option among others, not as a need imposed by design.
Why we write about this without having had to rescue anyone
We acknowledge that this article isn't based on the experience of having rescued clients from previous vendors. It's based on the technical judgement accumulated building systems that we want to survive our relationship with the client. Every decision we make in a project passes through the question: if tomorrow this client wanted to take the system, could they? The answer must always be yes.
This approach has a cost. It means more time in documentation, more time in transfer sessions, more rigour in how accesses and accounts are managed. But the cost is worth it: it's what distinguishes a vendor who treats each project as a sale from one who treats it as a professional relationship.
If you're evaluating vendors for an AI project, ask them these questions before signing: what would a handover look like if tomorrow we decided to change vendors? What documentation would we receive? What access? Is a post-delivery support period included? If the answers are vague or defensive, you already know what you need to know.
If you want to talk to us about a specific project —yours or one you're evaluating—, get in touch. Whether or not you end up working with MindRise, an honest assessment of the approach can save you significant problems down the road.