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

TL; DR

• Start with one complete workflow, not every spreadsheet. Choose a recurring operational problem with a clear owner, agreed rules and manageable dependencies.
• Migrate only the data that workflow needs. Bring across reference records, active work and necessary history. Keep unrelated analysis and archives separate.
• Document the rules before importing. Resolve identifiers, formulas, statuses, exceptions and access permissions instead of simply copying columns into a new interface.
• Reconcile a trial import and test real work. Account for every source row, verify relationships and totals, test permissions, and have an operator complete the process using the imported records.
• Control the switch before retiring the old workbook. Decide where new edits belong and how to preserve them if you need to return to the old process. Retire the spreadsheet workflow only after a complete operating cycle passes the agreed checks.

Agree what the developer is taking over

A code review, continued feature development and responsibility for the live service are different assignments. Write down which one starts now. A developer hired to investigate the app has not automatically agreed to respond when customers cannot sign in.

Also separate taking over from moving platforms. The next developer may be able to work in the existing repository and hosting accounts. Replacing the builder, transferring a database or changing the authentication provider adds another scope. Do not bundle those changes into a handover without a reason.

A useful first agreement names the app and baseline, the access being granted, the checks to perform and the expected output. It also identifies who can approve a production change. This makes a limited onboarding task possible even when nobody can yet estimate the next feature confidently.

Preserve a known version before changing anything

Start with the version people are using. Record its address and ask the developer to identify the corresponding commit, meaning the saved revision in version control, and deployment. Keep the current state available for comparison. When that link cannot be established, record the uncertainty instead of labelling the newest export as the production source.

For a Lovable project, GitHub integration supports two-way code synchronization on the active branch. Agree which branch and editing route each person will use. A connected repository is not necessarily an isolated copy that the founder can keep changing independently of the developer.

The export also needs a boundary. Lovable distinguishes code, frontend hosting, and backend services and data. A repository can be transferred while the database, authentication and storage remain elsewhere. List those dependencies before discussing a move away from the platform.

Do not rewrite the app to make it look presentable before inspection. Preserve the evidence of what works and what fails. A developer who sees the actual starting point can distinguish an existing defect from a problem introduced during the takeover.

Build the handover packet

Use the table as a shared working document. The founder supplies the product context and identifies accounts; the developer verifies technical details and fills the gaps. You do not need to invent an architecture description before approaching someone who will inspect it.

For each row, mark what is available, what was tested and what is still unknown. A link to an account is different from working access; a file named README is different from instructions that somebody has followed successfully.

Record a walkthrough with test accounts where possible. Show an ordinary task and an exception, such as a cancelled request or a rejected upload. Describe the intended outcome as well as what currently happens. A recording of a defect documents the defect; it does not turn that behaviour into a requirement.

Give access without giving away the business

Invite the developer through the services' access controls rather than sharing the founder's main login. Keep the domain, billing and recovery arrangements under the business's control. Agree the permissions required for the current assignment and review them when the assignment changes.

OWASP's secrets-management guidance recommends limiting access to secrets and documenting their purpose, rotation and dependencies. Apply that to the handover: the setup document names each required value and its protected location, not the production credential itself. An example configuration file can contain names and placeholders. Use separate test credentials for the rehearsal.

If a production key has already been exposed, have the responsible operator contain the exposure and revoke or rotate it promptly. Deleting it from the latest document is not sufficient. Plan and verify updates to dependent services as part of the response, rather than treating the leak as a cosmetic documentation problem.

Separate the database, user accounts and uploaded files

Ask which parts the test environment recreates and which it merely connects to. A new empty database demonstrates that the application can start. It does not demonstrate that existing customer records, accounts or uploads will survive a migration.

For example, Supabase database backups do not include objects stored through its Storage API. File metadata in the database is not the uploaded file. Include a separate inventory and recovery plan for files when the app depends on them.

Document the authentication provider, account configuration and identity references too. Keep real customer data out of a convenient public preview. Prefer synthetic records that preserve the important relationships and edge cases; any necessary use of production data requires an appropriate access and handling process.

When no migration is planned, say so. The developer can verify how the existing services are operated without moving them just to prove ownership of the code.

Run a handover rehearsal on a client portal

Hypothetical example. Suppose the app lets a client upload a document, an internal reviewer approve it, and the client see the decision. Another client must not be able to open that document. This is an acceptance exercise, not a Caemcore case study or a complete security assessment.

Ask the receiving developer to perform these steps using the written packet. Run them in an isolated environment with test files, test identities and non-production integrations.

1. Start from a clean checkout. Use the identified revision, documented runtime and dependencies. Follow the setup instructions and record every undocumented file, command or setting needed to make it run. Update the packet and repeat the affected steps.
2. Verify the environment before using it. Identify the database, file storage, authentication project and external endpoints. Route messages to a test destination and use sandbox payment settings where relevant. A different frontend address does not establish that the backend is separate.
3. Run the required journey. Client A uploads a test file, the reviewer records a decision, and Client A sees that decision after signing out and back in. Check the stored result as well as the screen. Repeat with the agreed rejection or correction scenario.
4. Check a forbidden action. Using Client B's test account, have the developer verify that access to Client A's record and file is refused, including a direct request to the resource. Record the request and result without exposing secrets.
5. Release a small, reviewable change. Agree a harmless change, such as a label, commit it and deploy it to the test environment. Check the original journey again. Identify the deployed revision and demonstrate how to return to the previous test release.
6. Rehearse the relevant recovery. Restore a disposable test record and file from the agreed backup process into an isolated destination. Confirm the relationship between them. Record any recovery step that was not tested and who must resolve it before taking operational responsibility.

The forbidden-action check follows OWASP's distinction between signing in and being authorized to access a resource. Its guidance calls for permission checks on every request and tests of the intended access rules. Testing only an administrator's successful journey leaves that question unanswered.

This rehearsal demonstrates a bounded capability: the receiving developer can use the packet to build, test and release the agreed version. It does not certify the whole application as secure, prove its performance under load or approve a production migration.

Turn failed checks into a bounded work plan

Ask for a handover report that separates four outcomes: verified behaviour, reproduced defects, missing access or documentation, and assumptions that remain untested. Each unresolved item should point to evidence, its effect on the next assignment, an owner and the next check.

For example, a missing test email credential may block the password-reset rehearsal. That finding does not establish that authentication must be replaced. Conversely, a portal that exposes another test client's file needs corrective work; a successful build does not cancel that result.

Separate restoring the baseline from adding features. An onboarding estimate should say whether it includes creating missing setup instructions and a test environment, or only inspecting what exists. Otherwise the founder may believe they bought a takeover while the developer believes they sold a report.

If the investigation produces a recommendation to replace code, use the separate guide to fixing or rebuilding an AI-built app to evaluate that scope. The reason to rebuild should be demonstrated by the application and its requirements, not by the fact that a new developer has arrived.

Name the production owner before closing the handover

Close the transfer with an explicit responsibility boundary: who receives alerts, who handles urgent failures, who approves releases and when the incoming developer's support obligation begins. Keep any remaining exclusions beside that agreement. Unanswered questions about data recovery should not disappear inside a general statement that the app is now maintained.

In our published escrow-platform rebuild case, the handoff document covered environment variables, deployment, dispute handling, the payment-provider contact and what monitoring watched for. It illustrates why operational instructions extend beyond the repository.

Retire obsolete access only after the replacement access and responsible owner have been verified, except where an exposure requires immediate containment. Keep the final packet with the project and update it when the setup or release process changes. The next handover should not require reconstructing the same decisions from chat.

About Caemcore

Caemcore builds custom software for companies that outgrew off-the-shelf tools.

Internal systems, integrations, web and mobile apps, and products built from scratch. Small senior team, Warsaw-based, working with clients across the EU, US and UK.

You get a price range and a timeline before development starts, a working demo every Thursday, and a final invoice that matches the number quoted on day one.

Built it on no-code or AI tools and it stopped changing? We start with an audit, not a quote. 30 minutes, free: what we keep, what we rebuild, what blocks launch, the range and the timeline.

You get that whether we work together or not.

FAQ

Can I start a handover without technical documentation?

Yes. Start with a walkthrough, the accounts you know about, the version in use and the behaviour you need to preserve. Ask the developer to price the work of discovering and documenting the missing setup. Do not describe an undocumented app as ready for immediate maintenance; make producing a usable handover packet part of the assignment.

Should I send the entire AI prompt history?

Keep it available, but lead with accepted product decisions and reproducible behaviour. Highlight prompts that explain an unusual rule or a change you could not finish. Label generated explanations as unverified until checked against the app. The developer should not have to read every abandoned idea to discover which requirements still apply.

Can I keep editing the app with AI during the takeover?

Agree a controlled route for changes first. Preserve the baseline, identify the active branch or project, and have one person decide what reaches the shared release. Record urgent fixes so the receiving developer tests the current version. Uncoordinated changes make it harder to tell whether a failed check belongs to the original app or to new work.

What if the developer asks to move everything into their accounts?

Ask which service requires a move and what problem it resolves. Request a setup in which the business retains appropriate ownership, billing visibility and recovery access. If a supplier-managed account is necessary, document the transfer-out procedure and what access or data you receive on exit. A repository invitation alone does not settle those arrangements.

Can the developer take over only one part of the app?

Yes, provided the boundary is explicit. Name the code and services they will change, the interfaces with the rest of the app, and the person who owns failures spanning both sides. Test the complete user journey across that boundary. Partial ownership is workable only when an incident cannot fall into a gap between two suppliers.

Sources

• Lovable — Sync your Lovable project with GitHub. Documentation on code export, two-way sync and the active branch. Checked 13 September 2026.
• Lovable — Deployment, hosting, and ownership options. Documentation distinguishing code, frontend hosting, and backend services and data. Checked 13 September 2026.
• OWASP — Secrets Management Cheat Sheet. Guidance on access to secrets, environment separation and credential lifecycle. Checked 13 September 2026.
• Supabase — Database Backups. Documentation explaining that database backups do not include objects stored through the Storage API. Checked 13 September 2026.
• OWASP — Authorization Cheat Sheet. Guidance on least privilege and checking permissions for each request and resource. Checked 13 September 2026.

The client-portal rehearsal is a hypothetical acceptance exercise. The linked Caemcore project is our own published case; it is not evidence of a universal handover process or guaranteed outcome.