Client Offboarding for AI App Builds: The Ownership Terms Agencies Must Set (2026)

Quick answer (2026): Client offboarding on an AI app build is the moment ownership stops being assumed and starts being tested. Five assets change hands, and only the first is the one agencies usually plan for: the source-code repository, the AI vendor accounts and API keys, the prompts and evaluation sets, the application data and its vector or embeddings store, and the hosting, domain, and deployment secrets. Name each one in the statement of work, decide up front whether it transfers, is licensed, or is retained, and the handover becomes a checklist. Leave any of them unsaid and the last week of a good project turns into a dispute. The single most-missed item on AI app builds is account ownership: an assistant running on your agency's own OpenAI or Anthropic account is not something the client can simply walk away with, no matter who owns the code.

Offboarding is an ownership test, not a task list

Most offboarding advice reads as a checklist: revoke access, send the final invoice, archive the workspace. That is fine for a marketing retainer. An AI app build is different, because what the client actually bought is ownership of a working system, and a system is not a single asset. It is a bundle of five, and each one can be owned, licensed, or withheld independently of the others.

The failure mode here is rarely malice. It is silence. Nobody wrote down who owns the embeddings index, or whose name is on the model-provider account, so the answer quietly defaults to whoever happens to hold it, which is usually the agency. That default is invisible until the relationship ends, and then it is the entire conversation.

This is a different question from platform vendor lock-in. Lock-in asks whether you can leave a builder; handover asks whether the client can leave you with everything they paid for. A build can be perfectly portable at the platform level and still hand over badly, because the accounts, prompts, and data were never assigned.

The five assets that change hands

Transfer, license, or retain is a real decision per row, not a formality. The next five sections give the term to set for each.

1. The source code and repository

The cleanest asset to hand over is the codebase, provided you deliver the repository and its history rather than a zip file. Transfer the git repo to a client-owned organization on the delivery date so the client inherits the commit history, issues, and CI config, not just a snapshot. GitHub's own repository transfer flow moves ownership without breaking history, and it should be a named step in your SOW.

The builder you used shapes how clean this step is. We work across Totalum, Lovable, and Bolt.new, and the ones that emit real, exportable code make the handover honest. The Totalum builder, for instance, generates a downloadable TypeScript and Next.js codebase and lets clients download the complete source code at any time, stating that the code is "100% yours" (Totalum, 2026). Lovable (lovable.dev, 2026) and Bolt.new (bolt.new, 2026) likewise produce exportable code and push to GitHub rather than trapping the app in a prototype. If you built on a tool whose output cannot leave the platform, say so before the engagement starts, because you cannot assign what you cannot export.

One honest caveat belongs in the same clause: owning the application code is not the same as owning a portable data layer, which is the subject of asset four.

2. AI vendor accounts and API keys

This is the asset that surprises clients, and the one agencies most often get wrong. If the app calls a model through your agency's OpenAI or Anthropic account, then on the day you offboard, the client owns code that will not run. The keys are yours, the billing is yours, and the rate limits are yours.

Set the term before the build: the client provisions their own model-provider accounts, and every key the app uses is rotated to client-owned credentials at handover. Put the account inventory in writing (which provider, which key, what it is for) and treat the rotation as an acceptance step, not an afterthought. An app that runs only on your account is not a delivered app.

3. Prompts, configs, and evaluation sets

The prompt IP is genuinely contested territory, and pretending it is not causes disputes. Three things live here: the system prompts and agent definitions, the runtime configuration, and the labeled evaluation set used to sign off the AI features. The default agency instinct is to treat all of it as reusable house knowledge. The client's instinct is that they paid for it, so they own it.

Both can be right if you separate them. Assign the project-specific prompts, configs, and the eval set built from the client's own data to the client. Retain, in writing, any general-purpose tooling or eval harness you brought to the project and reuse across clients. If you do not draw that line in the statement of work, you will draw it in an argument.

4. Application data and the vector store

A database dump is not a full data handover on an AI app. Retrieval features run on an embeddings or vector index, and that index is derived data the client cannot trivially rebuild without the original pipeline. Hand over both the primary data and the vector store in a documented, importable format, and record the embedding model and chunking settings used to build it.

Here the builder choice has a real cost. Totalum stores data in "its own secure database" rather than exposing raw PostgreSQL (Totalum, 2026), which is excellent for code ownership but means a migration off-platform is more work than a Postgres dump; builders such as Lovable and Bolt lean on PostgreSQL-backed data, which ports more directly. On the specific criterion of how cleanly the data layer hands over, a proprietary-database build is a weaker fit than a Postgres one, and your offboarding clause should budget for the migration rather than assume a one-click export.

5. Hosting, domain, and deployment secrets

The last mile is where clean projects still snag. The production domain often sits in the agency registrar, the deploy pipeline runs on agency-held keys, and the environment secrets were never rotated. Transfer the domain to a client-owned registrar account, hand over hosting or migrate the deployment, and rotate every secret to a client-held set. A domain you still control is a dependency the client never agreed to keep.

Three clauses to put in the SOW

You do not need a new contract; you need three sentences in the one you already use.

• Ownership schedule. A table listing the five assets and, for each, whether it transfers, is licensed, or is retained, with the delivery mechanism named.
• Account and key rotation. A clause stating the client provides model-provider accounts and that all keys and secrets rotate to client-held credentials at acceptance.
• Data and prompt assignment. A clause assigning the client's data, the derived vector store, and the project-specific prompts and eval set to the client, while reserving the agency's reusable tooling.

Tie all three to your statement of work so the handover terms live in the same document as scope and acceptance.

A worked handover

An agency delivers an internal knowledge assistant: a Next.js app, a data store, a vector index over 4,000 company documents, and a chat feature on a hosted model. Blended context, same team, two different endings.

The silent version. The code ships as a zip. The assistant runs on the agency's Anthropic account. The vector index lives only on the agency's deploy. Three months later the client wants to switch agencies and discovers they own a codebase that does not run, no embeddings, and a domain they cannot move. The handover becomes a two-week negotiation and a reputational dent.

The named version. On delivery, the repo transfers to the client's GitHub org with history intact, the client's own model-provider key is rotated in and verified, the primary data and the vector store export with a documented embedding config, and the domain and secrets move to client-held accounts. Offboarding takes an afternoon, and the client refers you to two others. Same work, opposite ending, decided entirely by what was written down at kickoff.

Where the agency keeps something, and where the client should push back

Two honest notes, because a one-sided framework is a sales pitch.

Retain what you genuinely reuse. A general evaluation harness, internal scaffolding, or a prompt library you bring to every project is your IP, and assigning it wholesale to one client is a mistake you will regret by the third engagement. Name it as retained, and license the client to use the compiled result.

And where the client loses: if the build sits on a proprietary data layer, "you own the code" is true but incomplete, because the data cannot be lifted as cleanly as the repo. A client should push back and ask for a documented export path and a migration estimate inside the offboarding clause, not a reassurance. Owning the code and owning an easy exit are not the same promise.

If you take one thing from this: an AI app is five owned things, not one. Write down who gets the repo, the accounts, the prompts, the data, and the domain at kickoff, and offboarding stops being a fight.

Action checklist

• List the five assets on every AI app engagement and mark each transfer, license, or retain before kickoff.
• Deliver the git repository with history, not a zip, and name the transfer step.
• Require the client to hold their own model-provider accounts; rotate all keys and secrets at acceptance.
• Assign project-specific prompts, configs, and the client-data eval set to the client; reserve reusable tooling in writing.
• Export both the primary data and the vector store, with the embedding config documented.
• Transfer the domain and hosting to client-owned accounts; treat a domain you still hold as an open dependency.