How to Hand Off an AI-Built App to a Developer

The code is almost never what stalls a handover. What stalls it is the environment variable nobody wrote down, the payment account registered to a personal email address, and the deploy step that exists only in your head. A developer taking over an app you built with AI needs repository access, a complete inventory of environment variables and where they live, the database schema with a note on what each table is for, a runbook for deploying, a list of what is already broken, and the external accounts transferred rather than borrowed. Assemble that and they are productive on day two. Skip it and you are paying them to interview you.

What a developer needs on day one

Assemble this before the first call, not during it. Every row you cannot fill in is a question that will otherwise be asked in week two at your hourly rate.

Third-party accounts deserve special attention. If the payment provider, the email sender and the file storage are all registered to a personal address you no longer check, the developer cannot rotate a key without you, and you have built a dependency on yourself. This is a milder version of vendor lock-in on an AI app builder, and it is worth fixing before anyone else touches the project.

Four gaps specific to apps built with AI

The commit history says nothing

A conventional project carries its own explanation in its history: why a thing was done, what was tried, what was reverted. An app assembled through a chat interface often arrives as a handful of enormous commits with generated messages. Nobody can read the intent out of it, so budget for the developer spending their first day reading the code instead of the log, and write a one-page summary of major decisions to compensate.

Secrets ended up in the code

Keys pasted into a file during a debugging session have a way of staying there. Search the repository for anything resembling a token before you grant access, and assume anything you find is compromised and needs rotating. Configuration belongs in the environment, a principle the twelve-factor guidance on config has stated plainly for over a decade, and AI builders do not enforce it.

The schema has no constraints

Generated schemas frequently arrive without foreign keys, unique constraints or not-null rules, because the application code was doing that work in a happy path that nobody tested. The data is usually fine until it is not. Tell the developer to expect this rather than letting them discover it while investigating something else, and see how to choose a database for an AI-built app for what should have been there.

Row-level permissions were never switched on

This is the one that bites hardest. Managed database platforms typically ship tables with row-level security disabled and expect you to enable and write the policies. An AI-built app that works perfectly in testing can be readable by any authenticated user, and the symptom is nothing at all until somebody looks. Supabase's row-level security documentation sets out the model; the equivalent exists on other platforms under different names. Check it before the handover, not after.

Write the runbook yourself

Deploy the application once, slowly, writing down every step as you take it. Do not describe the process from memory. The gap between what you remember doing and what is actually required is the single most reliable source of a lost afternoon.

1. Clone into a clean directory and install dependencies. Note the exact runtime version that works.

2. Copy the environment file and record which values are required to boot versus which are needed for specific features.

3. Run the app locally and note anything that fails without an external service.

4. Deploy to staging if one exists, or to production if not, recording the exact commands and where they are run.

5. Record how to roll back, and confirm the rollback works. An untested rollback is a rumour.

The known-broken list

Write down everything you already know is wrong, including the things you have been avoiding. Two reasons: a developer who finds an issue you knew about starts wondering what else you have not mentioned, and half the list is usually cheap to fix while they are already in that part of the code.

• Features that only work if used in a specific order

• The page that is slow and you never worked out why

• Anything you fixed by adding a delay or a retry

• Tests that are commented out, and why

• Errors that appear in the logs which you decided were harmless

That last category matters more than it looks. Errors you have learned to ignore are the ones that hide real failures, and they are a recurring theme in what happens when an AI-built app breaks in production.

Agree the shape of the work first

Handovers go wrong when nobody said out loud whether the developer is maintaining what exists or rebuilding it. Both are legitimate. Only one of them is what you budgeted for. A third path is bringing them on as a technical cofounder rather than a paid contractor, which raises a different question: see how much equity to give a technical cofounder after AI built your MVP before that conversation happens.

• Stabilise first, judge later. Ask for two weeks of fixes and observation before any rewrite decision.

• Name the parts that must not change. Usually the database and anything customer-facing.

• Decide who owns the accounts. Ideally you, with the developer added, never the reverse.

• Set the review rhythm. Weekly is enough, and it stops a rewrite happening by accident.

Once someone else is doing the work, the ongoing cost picture changes too. Hosting, third-party services and the developer's time now sit on the same line, and the usual expectations around what maintaining an AI-built app costs are worth revisiting at the same meeting.

The first two weeks

A handover is a process rather than a meeting, and the fortnight after it is when the pack you assembled either pays for itself or reveals what is missing.

1. Week one, the developer gets the app running locally and deploys one trivial change end to end. If that takes more than two days, something in the runbook is wrong and it is cheaper to fix now.

2. Week one, they read the known-broken list and tell you which items are quick. Take the quick ones immediately, because momentum matters more than sequencing at this stage.

3. Week two, they write down what they found that you did not mention. Treat this document as valuable rather than as criticism; it is the real state of the project.

4. Week two, agree what is maintenance and what is a project, and price them separately. Blurring the two is how a maintenance retainer quietly becomes a rebuild.

Book a thirty minute call at the end of each week for the first month. Handovers fail slowly and in silence, and the single most reliable warning sign is a developer who has stopped asking questions in week two.

Questions people ask

Should I tell them the app was built with AI?

Yes, immediately. They will work it out within an hour, and knowing in advance changes how they read the code. It also lets them look for the four gaps above deliberately rather than tripping over them.

Will a developer want to rewrite everything?

Some will, and occasionally they are right. The useful counter is to ask which specific parts and what breaks if they stay. A rewrite justified by concrete failures is a plan. A rewrite justified by taste is an invoice.

What if I lose access to the tool that built it?

Export the code and the schema now, while access is not in question, and store both somewhere you control. That single step converts a platform dependency into an ordinary project, and it is the same precaution that applies to any app you build with AI.

How much should the handover itself cost?

Budget for a few days of paid onboarding and treat it as part of the project rather than an overhead. A developer who spends day one reading with a complete pack in hand is far cheaper than one who spends week one guessing.