How to export your AI-built app and hand it to a developer

Download your AppX source project, check it locally, and prepare a developer handoff with tested workflows, service details, and clear acceptance checks.

AppX team · 2026-09-12

An AI-built prototype becomes much more useful when someone else can open the project, run it, and make the next change. A source download gives your developer the files. A good handoff explains what those files are supposed to do.

This guide walks through exporting an AppX project, checking it locally, and preparing a short handoff that lets a developer continue from a clear starting point.

Choose the version you want to hand over

Before downloading anything, test one complete user journey in your current app. For a running-club prototype, that might be opening an event, joining it, seeing the updated participant count, and leaving again.

Write down what worked and what you have not tested. If the participant list uses sample data or is saved only on one device, say so. A screen that looks finished can still need shared storage, sign-in, or error handling.

Keep a short recording of that journey alongside the export. It gives your developer something concrete to compare against. Our phone-testing guide explains how to check an AppX project in Expo Go before the handoff.

Download the project source from AppX

Open the project you want to continue and find its export or project-settings controls. The source download is labeled Download Code (ZIP) in the export dialog or Download Source Code in project settings.

1. Let your current generation or edit finish before choosing the version to export.
2. Download the source ZIP and keep an untouched copy.
3. Extract a second copy into a folder on your computer.
4. Open that folder in your code editor. Start with README.md and package.json.

AppX's source export includes project source and supporting Expo / React Native configuration. The exact files depend on the project. The download is a snapshot: downloading it again does not merge changes your developer has made locally.

If AppX reports that source code is not ready, a usable source revision is not yet available for that project. If it reports an access problem, check that you are signed in to the account that owns the project. Avoid treating an error response as a successful export.

Know what the ZIP can carry

A source archive gives you a starting point for development. Other parts of an application need their own handoff.

Also check whether images, fonts, or other assets load from remote URLs. Your developer should know which resources remain external to the project folder.

Run the exported app before making changes

Ask your developer to reproduce the current behavior first. That separates setup problems from problems introduced by the next edit.

Follow the exported README and use a Node.js version supported by the project's Expo SDK. In a typical AppX export, the initial commands run from the folder containing package.json are:

npm install
npx expo start

Keep the exported configuration files, including hidden files, when moving the project. Review dependency-install errors before changing package versions. If the project uses another package manager, follow its configuration consistently instead of mixing lockfiles.

Expo's development guide explains how to open the running project. Use Expo Go when the project's SDK and native dependencies support it; projects with additional native requirements may need a development build.

Then repeat the same journey you recorded in AppX. For the running-club example, confirm that joining changes the count once, leaving reverses it, and reopening the app behaves as expected. Keep local persistence and shared server data separate in your notes.

Include a short handoff document

The developer needs the product decision behind the code as well as the code itself. Use the following template with your own observations. The running-club details are illustrative, not a claim about an app we have shipped.

Project: Running-club event app
Export: [filename and download date]
Reference: [recording or screenshots of the tested version]

Main journey:
Open an event, join, see the participant count, then leave.

Verified behavior:
[What you tested, on which device, and what happened]

Data and services:
[Sample data, local storage, APIs, and who manages each service]

Known gaps:
[What is missing, broken, or still untested]

First requested change:
Show a clear message when an event is full.

Acceptance checks:
Joining the last available place succeeds once.
A further join is refused without changing the count.
Leaving opens a place again.

Keep unchanged:
Existing event navigation and the join/leave workflow.

Use the app-prompt template to clarify the main journey if your original description is still broad. A precise brief remains useful when work moves from AI-assisted editing to a developer.

Set up service access without putting secrets in the app

List the configuration variables your project needs and explain how the developer should obtain access. Use example values in shared documentation.

Expo documents that variables prefixed with EXPO_PUBLIC_ are included in client-side code and must not contain private secrets. Keep privileged credentials on a server or in the appropriate service configuration. See Expo's environment-variable guidance for the distinction.

If the prototype calls an external API, test both a successful response and a failed request. Confirm who manages that API and whether the developer has access to a suitable test environment. The exported app still depends on the services its code calls.

Agree where the next version will live

Keep the original ZIP as a reference and put the working copy under version control before development continues. Review the files for credentials and private data before adding them to a shared repository.

Agree whether the next stage will happen in AppX or in the developer's working repository. A downloaded ZIP should not be treated as automatic two-way synchronization. If you later download another AppX version, compare the changes deliberately before incorporating them.

Give the developer one bounded first task, such as the full-event message above. Review the changed behavior and rerun the original journey before adding another feature. That creates a useful first milestone: the developer can run your app, explain its dependencies, and make a change you can verify.

If you are starting with a client request, turn the brief into a testable prototype first. Then export the version you have checked, add the handoff notes, and continue from a shared understanding of what works.

Ready to build that starting point? Describe your app in AppX.

Try your own app idea

Describe your app in AppX →