Share and Update an AI-Built App After the Demo

After the demo: the part nobody plans for

The fun part of sharing an AI-built app is the demo. The harder part starts five minutes later. Someone asks for the link, and someone else wants the app private. A teammate finds a bug. Then an agent must change the app and not break the version that people already opened.

That is a small operations problem. A working app needs four things. It needs a stable URL and a way to review changes before they go live. It needs access control that fits the audience. It also needs an update path that survives handoffs between Claude, ChatGPT, Codex, Grok or the next agent that works on it. A handoff is a move of the work from one agent to another.

In short, keep the code in a Git repository. Connect the repository to a host such as Vercel, Netlify or Cloudflare Pages. Give reviewers one production URL.

Make each change on a branch. Review the change at the preview URL of the branch. Then merge the branch. Protect previews (and production, if necessary) with the access controls of the host. Make sure that you know how to roll back (go back to an earlier version).

Give the app one live URL

If every AI edit makes a new random link, nobody knows which one is current. Keep the three kinds of URL that your host gives you separate:

URL	What it shows	Who gets it
Production URL or custom domain	The current released version	Clients, users, anyone who bookmarked the demo
Branch or preview URL	The latest change on one branch	Reviewers of a specific change
Per-deployment URL	One exact build that never changes	You, for comparisons and debugging

Each host that connects to Git works this way:

• Vercel creates a preview deployment (a test build at its own URL) for each push to a branch other than the production branch. The deployment has a URL for the branch, and this URL always points to the latest commit of that branch (Vercel environments).
• Cloudflare Pages gives each branch an alias in the form <branch>.<project>.pages.dev. The alias points to the latest commit of the branch (Cloudflare preview deployments).
• Netlify builds a Deploy Preview for each pull request. The preview has an address such as deploy-preview-42--yoursite.netlify.app (Netlify Deploy Previews).

Send clients the production URL. If possible, put it on your own domain. Send previews only to the people who review that change.

Put the source in Git, not in a chat

An app that lives only inside one chat session is fragile. When other people start to depend on the app, move it into a repository:

1. Download or export the project from the tool that built it.
2. Create a GitHub repository. Push the files to it.
3. Add a short README.md. In it, write the build command, the output folder and where the app is deployed. Also list the environment variables that the app needs (names only, never values).
4. Connect the repository to your host. On Vercel, use the New Project page. On Cloudflare Pages, use Workers & Pages > Create application > Pages > Connect to Git. On Netlify, use Add new project > Import an existing project.

From then on, the repository is the source of truth (the one place that holds the correct version). Any agent that can read and write the repository can work on the app. The host deploys each change that lands on the production branch.

Choose who can open the demo

Some AI-built apps must stay private. A prototype can contain client names, test data, financial assumptions or unfinished workflows. Pick the gate (the access check in front of the app) that matches the audience:

Audience	Gate	Where to set it
Anyone	Public	Default on most hosts
A small group with one shared code	Password	Netlify basic password protection (Pro plans and above), or Vercel Password Protection (paid plans)
Named people who sign in with their own email	One-time PIN	Cloudflare Access on a Cloudflare Pages project
Your own team	Team sign-in	Vercel Authentication, or Netlify team login protection (Enterprise)

Previews often show unfinished work. Protect them even when production is public:

• On Vercel, Standard Protection protects every deployment except your production domains. It is available on all plans (Vercel Deployment Protection).
• On Cloudflare Pages, Settings > General > Enable access policy restricts preview deployments to your Cloudflare account. For the production pages.dev address or a custom domain, you need a separate Access application (Cloudflare docs).
• On Netlify, password protection can cover all deploys. This includes Deploy Previews and branch deploys (Netlify docs).

A long preview URL that is hard to guess is not authentication. Anyone who gets the link can open it.

Update the app without breaking the shared version

Keep the update loop boring:

1. Start a branch for one change, such as fix-signup-copy.
2. Ask the agent for a specific change. Tell it the page, what you tried, what happened and what you expected.
3. Push the branch. The host builds a preview.
4. Make sure that the preview works. Then send it to the reviewer who asked for the change.
5. Merge the branch into the production branch. The production URL updates, and everyone keeps the same link.
6. After the deploy, open production in a private window. Make sure that it works.

If a release breaks something, roll back first. Then find the cause. Each host has its own rollback:

• On Vercel, use Instant Rollback on the production deployment tile of the project. Hobby plans can roll back to the previous production deployment. Pro and Enterprise plans can choose any eligible earlier deployment (Vercel Instant Rollback).
• On Netlify, open an earlier successful deploy. Select Publish deploy. On a site that connects to Git with auto publishing on, the next production deploy replaces it. While you fix the problem, use Lock to stop auto publishing (Netlify docs).
• On Cloudflare Pages, open Deployments. Open the menu on an earlier production deployment. Select Rollback to this deployment (Cloudflare docs).

If the app has a database or server code, include data changes and server configuration in the release plan. A rollback of the front end does not roll back a database migration.

Collect feedback on the right version

Feedback is useful only when it refers to the version that the reviewer saw. Ask reviewers for three things: the URL, the action they tried, and the result they expected. Before you ask an agent to change code, reproduce the problem (make it happen again yourself).

Comment tools on preview builds help with this:

• Vercel Comments let reviewers pin comment threads to any part of a preview deployment. They are on by default for previews. Every commenter needs a Vercel account. To invite people outside your team, you need a Pro or Enterprise plan (Vercel Comments).
• The Netlify Drawer on Deploy Previews lets your team leave comments, screenshots, and video about a change.

Some clients will not create an account. For them, link a short form from the preview. The form asks for the page, the action, and the expected result.

Hand off between agents

One week, Claude can build the prototype. The next week, Codex can fix a layout bug. Later, ChatGPT can rewrite text or make a new data file. This works when the repository, not the agent, holds the project:

• Keep build and deploy instructions in the README.md (or an AGENTS.md that coding agents read).
• Store secrets in the environment variable settings of the host, not in the code or the chat.
• Give each agent session its own branch. Merge a branch only after you test its preview.
• Write down which branch is production and which URL clients use.

The host does not care which agent wrote the files. This keeps handoffs simple and prevents lock-in (dependence on one tool).

Built-in publishing or your own host

Some AI tools now publish for you. ChatGPT and Codex have Sites, and Grok Build publishes apps to grok.me addresses. Built-in publishing is often the easiest path when the full build and publish process stays inside one tool.

A repository and your own host are a better fit in these cases:

• More than one agent or tool needs to change the same app
• Clients need a URL on your domain that outlives any one tool
• You need preview URLs, access control, and rollback that you configure yourself
• You want the code to stay portable

Neither path is always better. Ask which problem you have. Do you want this tool to deploy the app? Or do you want any agent to update the app that your team already shared?

Before you send the link

Make sure that these statements are true:

• The production URL opens in a private window and shows the right version.
• The access gate works for a reviewer who is not on your team.
• Placeholder data, test accounts, and unfinished screens are hidden, unless the review needs them.
• The main flow works on a phone.
• You know how to roll back.
• The reviewer knows which URL is current and how to send feedback.

A docs portal with Ask AI
and support tickets

Connect a repository, or describe your product to start. Each docs site has search, Ask AI, an API console, an MCP server and support tickets.

• Publishes from GitHub on every push
• Works with Mintlify repositories
• API console from your OpenAPI file
• MCP server and llms.txt for AI agents
• Ask AI and support tickets
• Analytics for people and AI agents

Start Free→ Questions? Ask AI in our docs

No card required.