How to Hand a Vibe-Coded App Over to a Development Team

Start with what you own

Every major AI build tool now says, in its terms, that you own the output. Vercel's v0 FAQ puts it plainly: "Vercel doesn't own the code generated based on your queries and prompts" (Vercel, 2026).

Base44's terms, updated 22 June 2026, assign the customer all rights in the generated code and applications, subject to Wix's own platform ownership (Base44 Terms of Service, 2026). Lovable's terms, version dated 28 August 2026, say the same about your projects and your AI output (Lovable, 2026). Bolt's support documentation states that code you create is yours and can be used commercially (Bolt, 2026).

Those clauses answer one question and leave the other open.

Ownership of the code is settled. Whether the code runs without the platform is a separate matter, and that is the one that decides what a development team can do with it.

Base44's own support documentation is candid about this. The export covers client-side code and backend functions, and data comes out as CSV, one collection at a time (Base44 support documentation, 2026).

What it does not cover is managed hosting, the authentication system and the database infrastructure. Those stay put.

Lovable is a similar shape. Supabase's documentation states that where a project runs on Lovable Cloud, the underlying Supabase instance is owned and managed by Lovable rather than your own account (Supabase, 2026).

So it never appears in your Supabase dashboard, and you get no service role keys, the master credentials that let a developer reach the database directly.

Bolt does the same by default, then documents a way out. Supabase's troubleshooting notes confirm that a Bolt-provisioned project sits in Bolt's organisational account until you run the claim step that moves it into yours (Supabase troubleshooting documentation, 2026).

Replit is worth checking before you show anyone the repository. Its licensing documentation states that content created in a public Replit App is automatically subject to an MIT licence, which is the permissive open-source licence that lets anyone copy, modify and ship your code (Replit, 2026).

Most of the agency rescue pages I reviewed open with a code audit. Reasonable, but it starts one step too late.

Our free 30-minute App Assessment Call begins with what travels and what does not. A codebase that cannot leave its platform is a different engagement from one that can.

Treat every key as burned

If a secret has ever been shipped to a browser, assume it is public. Rotation is the only fix.

Moving the key to an environment variable does not undo the months it spent sitting in a bundle any visitor could read. This applies to hand-written frontends too.

OWASP, the open web security project whose guidance most engineers work from, is direct about rotating secrets regularly to limit the useful life of stolen credentials (OWASP Secrets Management Cheat Sheet, 2026).

The NCSC, the UK's National Cyber Security Centre, goes further in its API guidance. It calls for rotation to be automated with no human in the loop, and warns about secrets sprawl across systems (NCSC, 2026).

One distinction is worth holding onto, because the two get confused. The NCSC has moved away from forcing periodic changes of user passwords.

Machine credentials follow different rules from user passwords. Rotate the first aggressively, leave the second alone.

The natural moment for this is before anyone new gets access, treating the whole key inventory as compromised. The security failures we find in almost every AI-built codebase usually start here.

Write down what only you know

A developer can reconstruct what the code does. They cannot reconstruct what was promised.

Refund terms agreed by email, the customer who gets an exception on billing, the edge case handled manually every Friday, the integration account registered to a personal address. That knowledge dies quietly in a handover and resurfaces as a bug six weeks later.

Prompt history is not a substitute. None of the platforms examined treats the prompt log as a formal deliverable, and none documents an export designed for handover.

It records what was asked for, which is not the same as what the system now does.

Two hours of plain writing covers it: business rules, known edge cases, user commitments, and a list of every third-party account with who owns it.

Then freeze changes. Whatever ships after the assessment starts is a codebase the receiving team has not seen.

Sort the legal side first

If the app holds personal data, bringing in an agency makes that agency a processor, and UK GDPR Article 28 requires a written contract binding them before they touch it (ICO, 2026).

Worth being clear on the two words, because they decide who carries the risk. You are the controller, the one who decides what happens to the data. The agency is the processor, acting on your instructions.

The ICO is unambiguous on where responsibility then sits. Its guidance states that "a controller is primarily responsible for its own compliance" and for the compliance of its processors (ICO, 2026).

Corrective measures and fines can land on the controller whatever the contract says. That is worth knowing before the contract is signed rather than after.

While the contract is being drawn up, move the accounts properly. Stripe documents a formal ownership transfer through team settings, with a separate route for entity changes (Stripe, 2026).

Sharing a login is not a transfer, and it will fail an audit later.

Expect tests before anything changes

The technique for inherited code is not new. Michael Feathers set out characterisation tests in 2004: tests that pin down what the code currently does rather than what it should do, so changes can be made without silent breakage (Feathers, 2004).

Martin Fowler described the second approach in a post dated 29 June 2004, originally as the strangler application and now generally called the strangler fig. Traffic routes through a façade and the old system gets replaced piece by piece (Fowler, 2004).

Both remain current practice. The strangler fig is documented in AWS Prescriptive Guidance and the Microsoft Azure Architecture Center (AWS, 2026; Microsoft, 2026).

A big-bang rewrite, meaning everything replaced at once and switched over on a single date, is the higher-risk alternative. If a team proposes one before either of the above, it is fair to ask why.

Sometimes the answer is legitimate, and we have covered how to make the refactor-or-rebuild call properly.

Some apps are not transferable in their current state, and the marker is usually simple. If no secret can be rotated without breaking the app, or if the data only comes out as CSV, the budget is for a backend rebuild rather than a transfer.

Establishing which of those you are looking at is what a Platform Discovery Sprint is for, at a fixed £4,500 plus VAT, so the decision rests on evidence rather than on a quote written blind.