What to Ask For in Your AI Consultant's Handover Documentation

What to Ask For in Your AI Consultant's Handover Documentation

An AI system that works perfectly on the day your consultant hands it over and breaks silently three months later isn't a rare failure story — it's the predictable result of a handover that was a demo, not documentation. Here's what to actually ask for before an engagement ends, so the system survives contact with reality after the consultant leaves.

Why Handover Quality Matters More Than Build Quality

A well-built AI system with no documentation is a liability the moment something changes — an API updates, a team member who understood the system leaves, or a new integration needs to be added. The build quality determines whether the system works on day one. The handover quality determines whether it still works on day two hundred.

The Five Documents Worth Insisting On

1. A Plain-English System Overview

Not a technical architecture diagram alone — a document that explains, in language a non-technical team member can follow, what the system does, what triggers it, and what it produces. If your only understanding of the system lives in the consultant's head, you don't actually own it.

2. Access and Credentials Documentation

Every account, API key, subscription, and login the system depends on, clearly listed with who owns each one. This sounds obvious, but it's the single most common gap: a system built using the consultant's own trial accounts or personal API keys that quietly stops working once the engagement ends and those credentials lapse.

3. A Troubleshooting Guide for Common Failures

What are the two or three most likely things that will break, and what does that look like when it happens? A genuine handover anticipates failure modes rather than assuming the system will simply keep working indefinitely without intervention.

4. A Change Log or Version Record

What was built, in what order, and why key decisions were made along the way. This matters most when you need to modify the system later — either with the same consultant on a new engagement, or with someone else entirely.

5. A Clear Statement of What's NOT Included

Explicitly what ongoing maintenance, monitoring, or support is and isn't covered by the completed engagement. Vague handovers create false assumptions on both sides about who's responsible when something needs attention six weeks later.

Questions to Ask Before the Engagement Officially Ends

• Who owns each account, subscription, and API key the system depends on?
• If this breaks at 6pm on a Friday, what's the first thing my team should check?
• Is there a support period included after handover, and what does it cover?
• What happens if I want to make a small change myself without re-engaging a consultant?
• Where does the documentation live, and who has access to it?

The Handover Conversation Worth Having Before You Sign, Not After

The best time to define handover expectations is at the start of the engagement, as part of the scope — not as an afterthought once the build is finished. Ask directly: "What does handover look like, and what documentation is included?" before signing, and treat a vague answer as a signal worth probing further, not a detail to sort out later.

What a Thin Handover Actually Costs You

A system with no real documentation effectively locks you into that specific consultant for any future change, however small — not because they're being difficult, but because nobody else can safely touch a system they didn't build and can't fully understand from what's been left behind. A proper handover is what actually transfers ownership, not just working code.

Frequently Asked Questions

Should handover documentation be included in the base project fee?

Yes — genuine handover documentation should be part of the scoped deliverable, not a separate add-on charged after the fact. If a consultant proposes charging extra specifically for documentation, treat that as worth clarifying before you sign, not after the build is done.

What if my consultant used their own accounts to build the system?

This should be resolved before handover — either the accounts and credentials are transferred to your business's ownership, or new accounts are set up under your business from the start. A system still running on a consultant's personal or trial accounts after the engagement ends is a real operational risk.

How much support should be included after handover?

This varies by engagement and should be explicitly scoped upfront — common approaches include a defined support window (for example, 30 days) covering bug fixes, versus ongoing maintenance requiring a separate retainer. There's no universal standard; the point is that it should be explicit, not assumed.

Can I ask for handover documentation mid-engagement, not just at the end?

Yes, and it's often a good idea — reviewing documentation as the project progresses, rather than only at the very end, gives you a chance to flag gaps while the consultant is still actively engaged and can address them easily.

What if the consultant is reluctant to provide detailed handover documentation?

Treat reluctance to document the system properly as a genuine red flag, not a minor inconvenience — it either signals disorganised delivery or an intent to keep you dependent on them for any future change. Raise it directly before the engagement concludes.