How to White-Label an AI Build for a Client (What to Hand Over and What to Keep)

White-labelling an AI build means the client receives a finished, working product under their brand, with no visible trace of the tools, models, or process you used to build it. The code does not reference your agency. The interface does not say 'powered by Claude.' The documentation does not walk them through your Claude Code workflow. From the client's perspective, they commissioned a build and received a product - how you made it is your business.

This is different from a standard handover in one important way: in a standard project, a curious client might look at the git history and piece together your method. In a white-label engagement, the client has usually agreed - explicitly, in the contract - that the methodology, tooling choices, and internal prompt systems are the agency's IP. They are buying the outcome, not the recipe.

White-labelling suits a specific kind of client: one who wants a finished system their team can use and maintain, does not want to learn Claude Code or manage an AI workflow, and is willing to pay a premium for something they can call their own. If the client wants to learn the tools themselves or wants your prompts so they can run the system internally, that is a different engagement type and a different price.

A white-label delivery is not just the code. It is a complete package that lets the client's team own, use, and maintain the product without you in the room. Here is exactly what I include and what I keep.

The handover document is the piece most agencies underinvest in. It is a plain document - not a code comment, not a README buried in the repo - that a non-technical person on the client's team can read and understand. It covers what the product does, what it cannot do, how to submit a change request, and who to contact if something breaks. Writing it forces you to document the known limits of the build, which protects you from support requests outside the scope you delivered.

The client owns the product. You own the process. That distinction is the commercial foundation of a white-label business, and it is why a white-label build can be profitable even when the delivery looks finished and complete. The things you keep are the things that let you build the next client's product at half the cost.

Your CLAUDE.md templates are your most reusable asset - they hold the stack decisions, the file conventions, the no-go zones, and the session-opening prompts that make every new build start from a position of strength rather than from scratch. One good CLAUDE.md for a React and Supabase stack gets reused across ten client builds. It is never in the delivery package.

Your prompt library is the same category. The prompts that reliably produce a working authentication flow, a correct database schema, or a solid API endpoint are the accumulated result of trial and error across multiple builds. They represent real time spent figuring out what works - and they stay in your internal Claude Code Club skill files, not in the client's repository.

The contract is where the white-label arrangement gets made explicit. Without a contract that says so, a curious client can reasonably argue they should receive your process documents alongside the product. The key clauses to include are: IP ownership of methodology, tool and model confidentiality, a scope of support definition, and a change request pricing schedule.

IP ownership of methodology means one clause that states the client owns the built application and its data, while the agency retains ownership of the development methodology, tools selection, prompt engineering, and internal documentation used to build it. This does not need to be a page of legalese - three sentences in plain English is enough to establish the principle and prevent the argument later.

The support scope definition is equally important. White-label clients often assume ongoing support is included. It is not, unless you quoted it. Define it: what is covered in the handover period, what constitutes a bug versus a feature request, and what the change request rate is after delivery. The [what to put in an AI project contract guide](/blog/what-to-put-in-an-ai-project-contract) has the exact clauses I use.

One of the most common white-label handover mistakes is delivering a product that runs on the agency's API keys. The client is live, the product is working, and then the agency offboards a client or shuts down a key - and the client's product breaks. Before you hand over any white-label build, every account and every API key that the product depends on must be transferred to a client-owned account.

Transfer list for a typical AI build: the hosting account (Vercel, Railway, Fly), the database account (Supabase, Neon), any third-party API keys the product calls, the domain DNS if it is a client domain, and access to any model APIs if the product calls a model directly. The client creates the account, you configure it, you verify it works, you remove your own access. That sequence is the clean handover.

The exception is your own agency tooling that the client never sees - Claude Code, your internal Claude account, any skill files or automations that ran during the build. Those never transfer. The client does not know what powered the work, and they do not need to.

White-label builds command a higher price than standard client projects for a concrete reason: you are absorbing more responsibility. The client cannot see your process, so they cannot co-manage it. Every risk decision - stack choice, third-party service selection, architecture call - is yours alone. The premium compensates for that asymmetry.

The other pricing factor is the handover cost. Writing a handover document, transferring credentials, running a walkthrough call, and handling two weeks of post-delivery questions takes real time that does not show up in the build itself. Factor that into the quote rather than discovering it eats your margin after delivery.

One structure that works well: quote the build at your standard rate, then add a named 'white-label package' line item that covers the handover document, credentials transfer, the walkthrough call, and two weeks of bug support. Making it a visible line item - rather than hiding it in the build price - makes the premium legible to the client and makes it easy to reference in the contract. The [how much deposit to charge guide](/blog/how-much-deposit-to-charge-before-an-ai-project) covers getting that first payment secured before you start.

The optional walkthrough call is not a training session. It is a single 30 to 45 minute call that covers four things: a live demo of the product working as specified, a walkthrough of the handover document, confirmation that the client can access everything they own, and a clear statement of what is and is not included in the two-week support window. That is the full agenda. Do not use it to teach the client Claude Code or walk them through your build process.

Record the call with the client's permission. Send the recording alongside the delivery package. Clients who watch the recording after the call can answer most of their own early questions without creating a support ticket, which means your two-week window stays manageable.

After the two-week support window closes, anything new is a change request. State that explicitly on the last day of the support window - a short email that says 'Your two-week support period ends on [date]. From that point, changes are handled on the standard change request rate of [rate]. Here is how to submit one.' No ambiguity, no drift, no client who assumes they have ongoing support they did not pay for.