Who owns the code? The agency handoff guide

The client's new developer sends one message: "can you send me the repo." For a lot of agency work built with AI tools, the honest answer has been a login to somebody else's account.

That answer costs the next engagement. It's also the wrong answer to a question that's now in the contract.

Who owns the code when an agency uses an AI app builder for client projects?

You and the client, in whatever proportion your statement of work says. The tool shouldn't be a party to it, and the first thing worth verifying about any AI builder is that its terms say so in writing.

Clients stopped taking that on trust. About 40% of brand-agency contracts now carry AI-related clauses, and the IAB expects that share to double within one to two years (IAB State of Data 2026, scope: advanced measurement). The question is going into the paperwork before the work starts, which means your answer has to exist before you pitch, not after the invoice.

So write the assignment into the statement of work the way you would for a website: what transfers at final payment, what you retain (your prompt library, your templates), and who holds the domain. Agencies lose ownership arguments in the contract, not in the tool.

What "owning it" has to mean

A developer who inherits the project will ask for four things, and a client who "owns the code" without them owns a screenshot.

The repository. Real, current code in a place the client controls.
Runtime independence. The app runs and deploys somewhere other than the tool that built it.
The secrets. Every environment variable and service key, documented and rotated.
The hosting and the domain. On the client's account, or with a written plan for when they move.

Expect the developer to read the code before they trust it. In Veracode's 2025 study, 45% of AI-generated code samples failed security tests (Veracode), and any competent reviewer knows that number. Hand off assuming inspection.

Can agencies white-label apps built with AI tools?

Yes, on a paid plan. Bolt.new's custom domains are paid-plan only and attach to a published, public site (Bolt.new support). Free-tier sites show a "Made in Bolt" badge on preview and published pages; upgrading removes it on the next site update (Bolt Cloud hosting plans). Bring the client's brand system in so the screens inherit their type, color, and components, and the deployed app carries their name and their domain and nothing else.

Can I manage multiple client projects in one account?

Yes, on a Teams plan. It gives an agency a shared workspace, separate from each member's personal account, with one bill (Bolt.new support). The team admin sets access and integration permissions across every project in the team, and you can connect the team to your existing GitHub organization. Each member needs a paid seat to get tokens.

Three rules keep the clients apart. Keep production hosting on client accounts, because hosting limits apply per account rather than per project and one busy client can take every other client's site offline. Treat the GitHub organization, not the Bolt workspace, as the system of record for who owns which repo. And keep client-side people out of the agency workspace, sharing the running URL and the repo instead, so client separation never rests on workspace permissions.

How do I hand off an app I built with AI to a developer?

Five steps, in the order the client's developer will check them. The sequence holds for any builder you use; the mechanics below are Bolt's.

Sync the project to GitHub before you call it done. Bolt commits every change that doesn't break the project and checks the repository every 30 seconds for changes made outside Bolt, so the sync runs both ways (Bolt.new support). Create the repo under the client's GitHub organization, or push to yours and transfer it in GitHub at final payment. Branches you create in Bolt appear in GitHub; merges happen in GitHub.
Prove the code runs without the builder. The project is a standard web project. Bolt's own docs describe publishing through Bolt hosting, the Netlify integration, "or another service you choose" (Bolt.new support). Have the developer clone the repo and run it locally once while you're both still on the engagement. That ten minutes ends most ownership disputes before they start.
Hand over the secrets in their own note. Environment variables are never visible to project viewers (Bolt.new release notes, April 2026), which is the right default and also means they don't travel with a shared link. Document every variable and service key in a handoff note, then rotate the keys once the client's developer has them. Exports carry code, not secrets.
Move hosting and the domain to the client. Bolt Cloud limits apply to the account as a whole, not per project. The free tier caps at 10 GB and 333,333 requests a month, and sites go offline when the cap hits. Pro carries 30 GB and a million requests, with pay-as-you-go beyond it (Bolt Cloud hosting plans). Twelve client sites on one agency account share one cap. Put production hosting on the client's paid account, or on the infrastructure their developer runs, and make sure the custom domain is registered to the client.
Ship the security report with the app. On paid plans, Bolt runs a security audit from the Publish menu (Bolt.new support). Attach the report to the handoff with the list of what you fixed. A developer who receives an audit trail trusts the code more than one who receives a URL.

What Bolt.new's terms say about your client's code

StackBlitz's terms are one sentence on the point. The company "does not claim any ownership rights in and to any data, content or other material that you submit, publish, transmit, display on, through or with our Services" (StackBlitz Terms of Service).

StackBlitz takes no license back on what you build, requires no attribution on what you deploy, and holds nothing that ties the code to your Bolt seat. The two-way GitHub sync is that last clause working in practice.

That puts the platform outside the ownership question and leaves the two parties who were always in it. Check those three against whatever else you build on, because the terms are the part you can't fix at handoff.

The part nobody puts in the handoff doc

A clean handoff means the client can change the app without you. Some will. The agencies that keep the account are the ones who made the handoff so clean that the client trusts them with the next build, and who priced the maintenance retainer as a service rather than a hostage fee.

The next engagement ends with a developer asking for the repo. Send the link.

See how agencies run the whole cycle in-house with Bolt for agencies. The build that starts it is in the client portal walkthrough.

FAQ

Frequently asked questions

The agency and the client, as their contract assigns it. StackBlitz's terms of service state that the company doesn't claim ownership of anything you submit, publish, or build with Bolt.new, and nothing in the platform ties the code to your account. Put the assignment of rights, the domain, and what you retain (templates, prompt library) in the statement of work.

Sync the project to a GitHub repository the client controls, have their developer clone and run it once while you're still engaged, document and rotate every environment variable and service key, move hosting and the domain to the client's account, and attach the security audit report. In Bolt.new the GitHub sync is automatic and two-way, so the repo is current the day you hand it over.

On Bolt.new, yes with a paid plan: custom domains are paid-plan only and attach to published public sites, and the "Made in Bolt" badge shown on free-tier sites is removed when you upgrade. Apply the client's brand system so the deployed app reads as theirs.

A Bolt.new Teams plan gives you a shared workspace, centralized billing, and admin controls over access and integrations across all team projects. Hosting limits apply per account, so keep each client's production site on that client's account even when the build happens in yours.