Handing an AI-built project to a developer: what to prepare
What to prepare before a developer takes over a project built with Cursor, Claude Code or another AI agent: access, a one-page brief, agent files, secrets.
Leer en español →
Before you hand an AI-built project to a developer, make sure all the code is pushed to a repository you own, invite them to every service the app uses with their own login, and write a one-page brief: what the app does, who uses it, what's broken, what must not change. Add the agent's instruction files and a list of environment variable names, and set up a test account. Done well, the developer can start on day one without a single password changing hands.
This guide walks through the access checklist, what the brief should contain, why the AI's own files and history matter, how to handle secrets, and what to ask the developer for in return.
What does the developer need on day one?
Most delays in a handoff aren't technical. They're waiting for an invite, a missing file, or the one person who knows the Stripe password. Go through this list before the first call.
| Item | Why it matters | How to give it |
|---|---|---|
| The full code in a repository | Agents often leave files uncommitted; the developer can't see what isn't pushed | Run git status, commit, push, and check the repository on GitHub |
| Hosting (Vercel, Netlify, Replit…) | To read build logs and environment variables | Invite them to the team or project |
| Backend (Supabase, Firebase…) | To see the database, policies and functions | Invite them as a project member |
| Payments (Stripe) | To check webhooks and products | Invite them with a role that fits the work |
| Email, analytics, error tracking | These hold the evidence when something fails | Invite or share read access |
| Domain and DNS | Many launch problems live here | Read access, or be available when needed |
| A test account | So they can use the app without your personal login | A user with fake data in a test environment |
For code, invite them as a collaborator rather than sending a zip file. GitHub's guide to managing access to your repository shows where to do it.
What should the one-page brief say?
A developer reads code fast; what they can't read from the code is your intent. Keep the brief to one page with these headings:
- What the app does, in two or three sentences, and who uses it.
- What works and must not break, for example "sign-up and the weekly report are used daily".
- What's wrong, each problem with steps to reproduce, what you expected and what happened. Our guide on writing a bug report a developer can act on shows the format.
- What you want next, in priority order, and what can wait.
- Deadlines and constraints: a launch date, a budget ceiling, a client demo.
- Who decides: who approves changes and answers questions.
Why should I include the AI's files and history?
A project built with an agent carries decisions that never made it into the code comments. Give the developer:
- The instruction files:
.cursor/rules,AGENTS.md,CLAUDE.mdor the equivalent in your tool. They show the conventions the agent was told to follow. - The notable conversations: if a chat produced the payment flow or the database structure, export or copy the key parts. They explain why something was done a certain way.
- The known workarounds: "the admin page only works if you refresh twice" is exactly the kind of thing a developer needs to hear.
- What the agent touched last: if the latest sessions were messy, say so. That's where to look first.
If you're not sure what's in the project, list the tools you used and in which order. "Started in Lovable, exported to GitHub, then Cursor for three months" tells a developer a lot.
How do I handle passwords and API keys?
Don't send them. Invite the developer to each service with their own account, so their access can be removed later without changing anything else.
For the app's own configuration, give them a list of variable names, not values, in a file like .env.example:
VITE_SUPABASE_URL=
VITE_SUPABASE_PUBLISHABLE_KEY=
STRIPE_SECRET_KEY=
STRIPE_WEBHOOK_SECRET=
RESEND_API_KEY=If keys were ever pasted into an AI chat, committed to the repository or shared over email, plan to rotate them during the handoff. A developer will usually spot these anyway; see what to do with an API key exposed in your frontend.
Who should own the accounts and the code?
You, or your company. The repository, the hosting, the backend and the payment account should be in your name with the developer as a member, not the other way round. That way the project stays with you whatever happens to the working relationship. Questions about who legally owns AI-generated code are covered in plain words in who owns code made with AI tools; for anything contractual, check with a lawyer.
Should I keep prompting while the developer works?
Not on the same code. If you and the agent keep editing while the developer is fixing things, you'll create conflicts that cost time to untangle. Agree on a pause, or keep your experiments on a separate branch and let the developer decide what to merge.
What should I ask the developer for in return?
- A short written summary of what they found, ranked by risk.
- An estimate or fixed price for each fix before they start.
- Changes in small pull requests, so you can see what changed.
- An updated README and instruction files at the end, so the next session with your agent starts on the same page.
- A reminder to remove their access when the work is done.
Quick answers
Do I need to clean up the code before the handoff? No. Push it as it is. Cleaning it up with more prompts often makes the developer's first read harder.
Is a screen-share enough instead of access? For a first conversation, yes. For actual work, the developer needs their own access.
How long does a good handoff take to prepare? Usually an afternoon: the invites, the brief and the variable list.
Should I share my Lovable or Bolt account login? No. Export or sync the code to GitHub and share that, and invite them to the services behind it.
Ready to hand it over?
Our guide on documenting your app so someone else can take it over goes deeper on the long-term docs. If you'd like us to be the developer on the other side, our Cursor project help page explains how we pick up AI-agent projects, starting with a written review of the code, and you can run the free health check first or send us the brief.
