How to Prepare a Vibe-Coded App for a Developer Handoff

The first meeting with a developer about an AI-built app can turn into an inventory. Where is the code? Which account owns the database? What does this environment variable do, and who has the key? Is the sign-in page supposed to look like that? Each question takes time to answer, and some answers turn out to live in a chat history, a builder’s settings page or a former freelancer’s account.

This checklist covers what to gather before that meeting: the code in a repository you own, a short README, a list of environment variables and services, rotated keys, a record of every account and who controls it, the right level of access, the prompts that shaped the app, and a list of known bugs. It expands the preparation section of You Built It With AI. Here’s How a Developer Takes It Over, which covers the whole handoff, and ends with a checklist you can copy.

Vibe-coded app handoff: key facts

Question	Answer
Where should the code be before a handoff?	In a Git repository owned by your own account or your company’s organization, not the developer’s account or one you can only reach through the AI builder.
What should the README cover?	What the app does, who uses it, how to run it, which services it depends on, and what is unfinished.
How do you share API keys with a developer?	List the names, not the values. Share values through a password manager, or have the developer create new keys in accounts you own. Don’t paste them into chat or email.
What if a key was exposed?	Rotate it before anything else. GitHub’s documentation says that for a leaked secret, “as a first step you need to revoke and/or rotate that secret.”
What access should the developer get?	Enough to do the work and no more. On GitHub, an organization repository’s Write role covers day-to-day code changes; Admin includes deleting the repository.
Should you share your prompts?	Yes. Project knowledge, saved instructions and chat history show what you meant to build, which helps a developer see where the code drifted from it.
Does the app need to be fixed first?	No. An honest list of known bugs and priorities is more useful than a last round of AI fixes.

What does a developer need from you before a handoff?

Eight things, each covered in its own section below:

Item	Why it matters	Where it may be now
1. Code in a repository you own	The developer works from it, and you keep control if the arrangement ends	Inside the AI builder, or a repository the builder or a freelancer created
2. A short README	Lets someone new run the app and understand what it is for	Nowhere, or in your head
3. Environment variable and service list	The app won’t run without its configuration	The builder’s settings, a local .env file
4. Rotated keys	A leaked key still works until it is revoked	Chat threads, emails, the repository’s history
5. Account and ownership record	Data, sign-in and files each live in a separate service	Several dashboards, sometimes under different logins
6. Access with the right permissions	Too little blocks the work; too much is a risk	Shared passwords
7. Prompts and decisions	Explain what the app is supposed to do	The builder’s chat history and settings
8. Known bugs and priorities	Point the first paid hours at what matters most	Notes, memory, customer emails

1. Get the code into a Git repository you own

A Git repository holds the code and the history of every change to it. It is the developer’s starting point, and owning it means the code stays with you if the developer, the freelancer or the AI tool changes.

Lovable, Bolt, Replit and v0 can all sync a project to GitHub. When you connect one, choose your own account or your company’s organization as the destination. Lovable’s GitHub integration lets a workspace connect to a GitHub account or organization and create repositories there. Exporting From Lovable, Bolt, Replit or v0: What You Get covers each tool’s export in detail, including what stays behind on the platform.

A few points to check:

• The repository is private. GitHub’s repository overview explains that public repositories “are accessible to everyone on the internet,” while private ones are limited to you and the people you give access to.
• You are the owner. If a freelancer or an earlier developer created the repository under their own account, ask them to transfer it to you. GitHub’s transfer guide says issues, pull requests and the wiki move with the repository, and the previous owner keeps collaborator access afterward, so remove that access if it is no longer needed.
• An organization gives finer control. GitHub’s guide to personal repository permissions notes that when a private repository belongs to an individual’s account, collaborators get write access and “can’t have read-only access.” A free organization owned by your business allows the role choices described in section 6.
• The latest changes are in it. Replit’s project copy guide points out that GitHub only receives what has been committed and pushed. Make a small visible change in the builder and confirm it appears in the repository.

If the app was built in ChatGPT or Claude’s chat, the code exists only in the conversation. Put them into a project folder with the same file names the AI used and commit that folder to a new repository. A developer can sort out the structure, but only if every file is there.

2. Write a short README for the developer

A README is the text file at the top of a repository that explains the project. GitHub’s documentation on READMEs lists what one typically covers, including what the project does, why it is useful and how to get started with it. For a handoff, one page is enough. It doesn’t need to be polished.

A template to fill in:

# App name

## What it does
One paragraph: what the app is for and who uses it
(customers, staff, admins).

## Status
Live with real users / in testing / prototype.
Real customer data? Yes / no. Payments live? Yes / no.

## How it was built
AI tool(s) used, and whether the tool is still synced
to this repository.

## How to run it
The commands you or the AI tool used, if known.
Leave blank if unknown; the developer will fill this in.

## Services
See "Services and accounts" below or the separate list.

## Environment variables
Names only. Values are shared separately.

## What's unfinished
Features that are half-built, placeholder pages,
anything that only works on the happy path.

If you don’t know how to run the app, leave that section blank. Part of a developer’s first job is getting the app to run from a fresh copy of the repository and writing down the steps that worked.

If you built with an AI coding agent that works in the repository, there may already be an instructions file. Claude Code, for example, reads a project CLAUDE.md file, which its memory documentation says is “shared with your team through version control.” Point the developer to it in the README.

3. List environment variables and services, not their values

Environment variables hold the settings that change between copies of an app, such as database addresses and API keys. The Twelve-Factor App, Adam Wiggins’s methodology for building web apps, defines this configuration as “everything that is likely to vary between deploys” and calls for “strict separation of config from code.” Its test for whether that separation is complete is whether the code “could be made open source at any moment, without compromising any credentials.”

For a handoff, write a list with one line per variable:

Variable name	What it’s for	Where the value comes from	Secret or public?
VITE_SUPABASE_URL	Database address used by the browser	Supabase project settings	Public
STRIPE_SECRET_KEY	Charging customers	Stripe dashboard, API keys	Secret
RESEND_API_KEY	Sending account emails	Resend dashboard	Secret

The names above are examples; use the ones your app reads. Builders that store environment variables list them in project settings, and a developer can find the rest by searching the code.

Write down names and sources, and share no values. OWASP’s Secrets Management Cheat Sheet makes the underlying point while discussing access to secrets: once a person can read a secret, “the secret can now leak through that user and the system they used to touch the secret.” A key pasted into an email or a chat thread stays in that thread, in every inbox it reached and on every device that synced it. Share values through a password manager’s sharing feature, or invite the developer into the service so they can create their own key.

Some values can’t be copied out at all. Lovable’s secrets documentation describes stored secrets as write-only: “its value can never be viewed again in Lovable, only replaced or deleted.” Replit’s copy guide states that “Secret values never leave the old project.” In both cases a new value has to be created in the provider’s own dashboard, which is one more reason the next section matters.

Not every value in the list is secret, and the prefix tells you which way to treat it:

• Public browser values. v0’s full-stack apps guide explains that variables for browser code need the NEXT_PUBLIC_ prefix, and Vite apps, including Lovable’s, use VITE_. Lovable’s secrets page says its VITE_ values, such as VITE_SUPABASE_PUBLISHABLE_KEY, are built into the browser code “and are safe to be public.” Lovable commits its .env file of these values to the repository on purpose and warns against listing it in .gitignore, because its previews depend on it.
• A secret in a public variable. A secret key placed in a VITE_ or NEXT_PUBLIC_ variable is exposed to everyone who loads the app. That belongs in section 4.

4. Rotate any keys that were exposed

A key is exposed if it has been anywhere other people or systems could read it: committed to a repository, placed in a browser-facing variable, pasted into a chat with a freelancer, sent by email, or shown in a screenshot or screen recording. Deleting the message or the file doesn’t undo that. GitHub’s guide to removing sensitive data is direct about the order: “as a first step you need to revoke and/or rotate that secret.” Once rotated, the old value stops working, and the guide adds that rewriting the repository’s history may then not be needed.

Rotating means creating a new key in the service’s dashboard, updating the app to use it, and revoking the old one. OWASP’s cheat sheet says that when secrets are “potentially compromised, you must securely revoke them to restrict access.” If you aren’t sure whether a key was exposed, treat it as exposed.

Keys stored in the AI builder’s own secrets settings are a different case. v0’s project settings provide encrypted environment variables “so you don’t have to expose them directly in your prompts,” and Lovable’s secrets page says that when you paste a key into its project chat, Lovable saves it as a project secret. A key entered only through the builder’s secret fields is not exposed. One copied into a general-purpose chat, a shared document or a message to another person should be rotated.

Rotating before the handoff, rather than after, also means the developer starts with keys that only you and they have seen. AI-Built App Security Checklist: What a Developer Checks First covers how a developer looks for keys exposed in the code itself.

5. Document every account the app uses and who owns it

The repository holds code. The running app also depends on services that each have their own account: the database, user sign-in, file storage, email, payments, hosting and the domain. The Twelve-Factor App calls these backing services and treats each one as an “attached resource” reached through the app’s configuration. For a handoff, each one needs a line in a list:

Service	What it does in the app	Account login (email, not password)	Who owns it	Who pays	Notes
Database	Stores users, orders, bookings				Real data? Backups?
Sign-in	User accounts and passwords				Providers: email, Google
File storage	Uploaded images and documents
Email sending	Sign-up, password reset, receipts				Sending domain
Payments	Checkout, subscriptions				Live or test mode
Hosting	Runs the live site
Domain registrar	The app’s web address				Renewal date
AI builder	Where the app was built				Still synced?

Ownership is the column that matters most. Look for services set up under a freelancer’s account, a personal email address you no longer use, or the AI builder’s own accounts. v0’s database documentation notes that adding a database through its marketplace “provisions a new user account on that service.” Lovable, Bolt and Replit can run the database, sign-in and storage inside their own platforms, in which case the builder account is the owner. The export guide’s section on what stays behind on the platform lists what has to be moved separately.

For the database, add a few notes a developer will ask about:

• Real or test data? Whether real users, customer records or payments exist yet.
• Backups. Whether any exist and where.
• Environments. Whether there is a separate development database. Replit, for example, keeps development and production data apart: a published app gets a production database distinct from the one used while building.
• The tables. If you know them, list the main tables and what each holds. A developer can read the structure from the database, but your description of what each table means is harder to recover.

6. Give the developer access with the right permissions

OWASP’s Authorization Cheat Sheet describes least privilege as “assigning users only the minimum privileges necessary to complete their job.” It also notes that “it is easier to grant users additional permissions rather than to take away some they previously enjoyed.” Start with what the first piece of work needs and add access as it grows.

Invite, don’t share your login. Give the developer their own account or membership in each service rather than your password. Their changes are then recorded under their name, you can remove them without changing your own password, and your account’s two-factor authentication stays with you.

GitHub. For a repository under your own user account, invite the developer as a collaborator. For an organization’s repository, GitHub’s repository roles run from least to most access:

Role	GitHub’s description	Fits
Read	“Recommended for non-code contributors who want to view or discuss your project”	Someone reviewing the code before quoting
Triage	“Recommended for contributors who need to proactively manage issues, discussions, and pull requests without write access”	A project manager
Write	“Recommended for contributors who actively push to your project”	A developer doing the work
Maintain	“Recommended for project managers who need to manage the repository without access to sensitive or destructive actions”	A lead developer managing settings
Admin	“Recommended for people who need full access to the project, including sensitive and destructive actions like managing security or deleting a repository”	You, the owner

Read access is enough for a developer to assess the app before quoting. Write access covers ongoing work.

The AI builder. Builder roles differ by tool and decide more than code access:

• Lovable. In Lovable’s collaboration roles, editors can edit the project, publish it and manage the GitHub connection, while only the owner can transfer or delete it. The same page notes that “Collaborators will use credits from the project owner’s workspace.”
• Bolt. Bolt’s collaboration guide states that if a project has a database, “collaborators can view the same data and make changes to the structure,” while the GitHub integration stays under the project owner’s control.
• Replit. Replit’s collaborator roles for team workspaces include Guest, which “Can only access and edit apps shared with them,” and Viewer, which has read-only access.

The database, hosting and payments. Where a service offers team members or roles, invite the developer with a role that covers the planned work. The production payment account and the domain registrar can stay with you, with access granted only for a specific task.

When the work ends. Remove access you no longer need, and rotate any shared secrets the developer handled. The same OWASP cheat sheet, writing about permissions inside an app, recommends periodic reviews for “privilege creep,” and the idea applies to the accounts around it too.

7. Collect the prompts and decisions behind the app

An AI-built app’s behavior comes from a long series of prompts and corrections. Decisions inside it, such as what happens when a payment fails or who can see which records, may have been made in conversation and never written down. The prompts are the closest thing to a specification.

Some of that context sits in the builder rather than the repository:

• Lovable keeps project knowledge in project settings. Its suggested contents include “What the application does,” “Database schema or key tables” and “Architecture decisions.”
• Bolt keeps project knowledge in project settings, described as “background instructions for Bolt to follow for a specific project.”
• Replit has Custom Instructions and Memories. Its documentation notes that Memories are “private by default,” and sharing with collaborators “is optional and off by default.”
• v0 saves Instructions to your account and applies them across your chats.

Copy these into the repository, for example as a docs/ai-instructions.md file, so a developer with repository access can read them. Then add a short decisions list in plain language:

• Rules the app must follow (“only admins can issue refunds,” “customers can only see their own bookings”).
• Choices you made deliberately and want kept.
• Things you asked the AI to fix repeatedly, and whether the fix held.
• Anything you told the AI not to do.

Full chat transcripts are useful as background, but a one-page summary of the decisions is what a developer will read first. Before sharing transcripts, check them for pasted keys or customer data, and rotate any key you find.

8. List known bugs and priorities

List every feature and mark each one: works, works with known bugs, or broken. For each bug, note what you did, what you expected and what happened instead. A screenshot or a short screen recording helps, as long as it doesn’t show keys or customer data.

GitHub Issues is built for this: its documentation says issues “can track bug reports, new features and ideas, and anything else you need to write down or discuss with your team.” One issue per bug, in the repository you own, keeps the list next to the code and gives the developer a place to reply. A plain document works too.

Then rank the work:

1. Must fix before launch or before more users arrive. Security problems, anything involving payments or personal data, anything that loses data.
2. Should fix soon. Bugs customers notice or complain about.
3. Can wait. Cosmetic problems, nice-to-have features.

Add deadlines that matter, such as a launch date, a demo or a renewal, and the budget range you have in mind. Both affect what a developer recommends doing first.

Vibe-coded app handoff checklist

Copy this into a document or a repository issue and work through it before the first call.

VIBE-CODED APP HANDOFF CHECKLIST

1. Code
[ ] Code is in a Git repository owned by my account or my company's organization
[ ] Repository is private
[ ] Latest changes from the AI builder are in it (test with a small change)
[ ] Anyone who no longer needs access has been removed

2. README
[ ] What the app does and who uses it
[ ] Status: live, testing or prototype; real data and payments yes/no
[ ] Which AI tool built it, and whether it is still synced
[ ] How to run it (if known)
[ ] What's unfinished

3. Environment variables and services
[ ] Every variable name listed, with what it's for and where the value comes from
[ ] Each variable marked secret or public
[ ] No secret values in the list, the README, chat or email

4. Exposed keys
[ ] Checked for keys in the repository, browser-facing variables, chats, emails and screenshots
[ ] Every exposed or uncertain key rotated and the old one revoked

5. Accounts and ownership
[ ] Database, sign-in, file storage, email, payments, hosting, domain and AI builder listed
[ ] Account owner and billing owner noted for each
[ ] Accounts held by a freelancer or an old email address moved to me
[ ] Database notes: real data, backups, development vs. production, main tables

6. Access
[ ] Developer invited with their own account in each service (no shared passwords)
[ ] GitHub role chosen: Read to assess, Write to work
[ ] Builder, database and hosting roles match the planned work
[ ] Plan to remove access and rotate shared secrets when the work ends

7. Prompts and decisions
[ ] Builder knowledge, instructions and custom rules copied into the repository
[ ] One-page list of business rules and deliberate decisions
[ ] Chat transcripts checked for keys and personal data before sharing

8. Bugs and priorities
[ ] Every feature marked: works, buggy or broken
[ ] Each bug written up with steps, expected and actual result
[ ] Work ranked: before launch, soon, can wait
[ ] Deadlines and budget range noted

What to avoid when handing off an AI-built app

• Pasting secrets into email, chat or a shared document. Share them through a password manager or have the developer create their own keys.
• Giving the developer your own login. Invite them as a member instead.
• Granting owner or admin access by default. Start with what the first task needs.
• Prompting the builder on the same branch the developer is working on. With two-way sync, both sets of changes land in one place. Agree on who changes what, or use separate branches.
• A final round of AI fixes just before the handoff. It changes the code the developer is about to assess and can hide what was going wrong.

When to bring in a developer

A prepared handoff is most useful before real users, personal data or payments go live, and before a deadline is close enough to limit the options. If you have worked through the checklist above, a developer can spend the first hours on the app itself rather than on finding it.

If you’d like help, the process and pricing are published, and you can get in touch to talk through what you’ve built.