The AI App Handoff Checklist: What to Deliver So the Client Can Run It (2026)

Quick Answer (2026): A clean AI app handoff is more than a repo and a README. Because an AI feature leans on things that live outside your codebase, an agency has to hand over two layers, not one. The classic software layer is the source code, environments, credentials, and tests. The AI layer is the provider account and API keys in the client's name, the prompt library, the labeled evaluation set and the accuracy baseline you signed off on, token and cost monitoring, and a pinned model version with a plan for when it is retired. Deliver both layers plus a one-page runbook, and the client can actually own and run the app. Skip the AI layer, and they are back on your calendar the first time a model changes.

The handoff is where AI projects quietly go wrong. Not on launch day, when everyone is happy and the demo works. Three weeks later, when the client wants a tiny copy change and cannot find the repo, or the OpenAI bill lands on your agency card instead of theirs, or a model is deprecated and nobody has the account to swap it. A weak handoff turns a delivered project into an unpaid support contract. This is the AgencyOps checklist for handing over an AI build so it stays handed over.

A generic handoff checklist covers half the job

The canonical advice on handing off a software project is solid and still applies: transfer the source with its history, write a README that covers setup and deploy, pin your dependencies, leave automated tests, move third-party account access, and do some housekeeping so the next person is not reading dead code. Every one of those items matters for an AI build too.

The problem is that an AI feature depends on a second set of things that a normal web app does not have, and none of them live in your git repo. The model runs on someone else's servers. The behavior is shaped by prompts that are easy to lose and hard to reverse-engineer. The quality is a number you agreed to, measured against data the client may never see again. And the whole thing can change under you when a provider ships a new model or sunsets an old one. Hand over a spotless codebase and forget that second layer, and you have handed over a car with no keys and no fuel.

The AI app handoff package

Here is the full package AgencyOps hands over at launch. The top half is the classic software layer. The bottom half is the part almost every generic checklist misses.

Print that table. It is the difference between a client who runs their app and a client who owns a black box they are afraid to touch.

The one decision nobody documents: who owns the account and the keys

If you fix only one thing about your handoffs, fix this. The API keys and the model provider account should be in the client's name before you leave, not yours.

When you build fast, it is tempting to run everything through the agency's own OpenAI or Anthropic account. It is one less onboarding step and you already have billing set up. Then the project ships, and now the client's production app is authenticating against your account. Their usage counts toward your rate limits. Their spend hits your card and you re-bill it, which is a reconciliation chore that never ends. Their data is governed by your account's training and retention settings, not choices they made. And if you ever stop paying that bill, their app goes dark. We wrote a whole piece on billing clients for AI API costs, and the cleanest answer is almost always the same: the client holds the account, you get delegated access during the build, and at handoff that access is revoked.

This is also where the underlying build tool decides whether a clean handoff is even possible. You can only hand over an app the client genuinely owns if the code itself is theirs: a standard, exportable codebase they or any other shop can run, not a hosted prototype you can only edit inside one vendor's canvas. Tools differ sharply here. Lovable and Bolt both let you export the generated project, so there is real code to transfer. An AI app builder like Totalum goes further and hands over the complete Next.js and TypeScript codebase, database, and deploy configuration, with the code, in its own words, "100% yours" and no vendor lock-in. On the other end, some no-code and chat-to-app tools keep you renting their runtime, which means there is no self-contained artifact to deliver, only a login. The honest trade-off runs both ways: an owned codebase is more to maintain than a hosted no-code app, so if the client has no technical capacity at all, exportable code they cannot read may not help them. Match the tool to who is receiving the handoff, not just to your build speed.

Hand over the eval set, not just the number

The accuracy figure you agreed to is only trustworthy if the client can reproduce it. When you set an accuracy target and a floor during scoping, you built a labeled evaluation set to prove it. That set is a deliverable. Hand over the data, the harness that runs it, and the baseline result, tied back to the acceptance criteria the client signed. Now, when someone changes a prompt or swaps a model six months from now, they can re-run the same set and see whether quality moved, instead of guessing. An eval set left on your machine is worth nothing to the person who owns the app.

The runbook: what breaks after you are gone

Traditional apps mostly break when someone changes the code. AI apps also break when nobody changes anything, because the ground moves. Give the client a one-page runbook that names the failure modes and the response:

1. Cost spike. A dashboard alert fired. Here is where to see usage, the likely cause (a loop, a traffic surge, a bigger model), and the kill switch.
2. Quality drift. Outputs feel worse. Re-run the eval set. If the number dropped, here is what changed, usually a provider-side model update.
3. Provider outage. The model API is down. Here is the status page and the fallback behavior the app was built to use.
4. Model deprecation. The provider is retiring the pinned model. Here is the config line to change and how to re-run the eval set before and after to confirm quality held.

Four scenarios, one page. It converts a panicked "the AI is broken, call the agency" into a task the client can handle, which is exactly what a real handoff is supposed to buy them.

Where a full handoff is the wrong move

Not every client should get the keys and be waved off. If you sold a managed engagement, the point is that you keep running the app, so a full transfer would contradict the deal. Some clients have zero technical staff and would be actively worse off holding a codebase they cannot maintain; for them the honest recommendation is a maintenance plan, and a support retainer beats a handoff that leaves them stranded. And there is a difference between this launch handoff, the deliverables package that lets the app run, and the contractual ownership and exit terms you agree at the end of a relationship. Decide which one the moment actually calls for, and price the ongoing option honestly rather than defaulting to "here is a zip file, good luck."

The five-minute handoff check

Before you send the "it's all yours" email, confirm every line:

• Repo is in the client's org, with history, and you can still see it only because they invited you.
• README plus deploy guide are current, and a teammate who never touched the project could follow them.
• Environment variables are documented and staging plus production both come up clean.
• The model provider account is in the client's name and the API keys are theirs.
• Every production prompt is in a versioned library with a one-line reason for each.
• The evaluation set, its harness, and the signed baseline number are handed over.
• A spend dashboard and a budget alert are wired to the client's billing.
• The pinned model version and a deprecation plan are written down.
• The one-page runbook is in the repo, not just in your head.

If you take one thing from this: a handoff is not "we gave them the code." It is "the client can run, pay for, measure, and repair this app without us." The AI layer, the account, the prompts, the eval set, and the runbook, is what makes that true. Deliver it and the project is actually done. Skip it and you are the maintenance plan, unpaid.

FAQ

What should an AI app handoff checklist include?
Two layers. The classic software layer is the source code and full git history in the client's own organization, a README and deploy guide, documented environment variables, third-party credentials moved to a client-owned vault, and the automated test suite. The AI layer is the model provider account and API keys in the client's name, a versioned prompt library, the labeled evaluation set with its signed accuracy baseline, token and cost monitoring wired to the client's billing, and a pinned model version with a deprecation plan. Add a one-page runbook and the handoff is complete.

Who should own the OpenAI or Anthropic API keys after a project ships?
The client. If production runs on your agency's account, their usage eats your rate limits, their spend hits your card, and their data follows your account's retention and training settings. Set up the provider account in the client's name, take delegated access during the build, and revoke that access at handoff so the billing, limits, and data controls are all theirs.

Why hand over the evaluation set and not just the accuracy percentage?
Because a number nobody can reproduce is not evidence. The labeled eval set, the harness that runs it, and the baseline result let the client or a future developer re-verify quality after any prompt change or model swap. Without it, the accuracy you agreed to becomes an argument the first time an output looks wrong.

How is a launch handoff different from client offboarding?
The launch handoff is the deliverables package that lets a client run the app the day you finish: code, accounts, prompts, eval set, and runbook. Offboarding is the contractual and relationship exit, the ownership and IP terms you agree at the end of the engagement. You can hand off cleanly at launch and still have an ongoing relationship, and you can offboard a client you handed off to a year ago. They are different moments and need different documents.

Do AI apps built with no-code tools break more often after handoff?
They fail differently. An AI app can degrade with no code change at all when a provider updates or deprecates a model, so the risk is real regardless of how it was built. What matters for handoff is whether there is a self-contained, exportable codebase to transfer. Tools that export standard code give the client something to own and maintain; tools that keep the app inside a hosted runtime leave only a login, which is harder to hand off and harder for a new developer to take over.