How to publish an AI-built web app

🚀 Publishing means releasing one proven version

An AI-built web app can look finished while it is still a private preview. Publishing makes a named version reachable at a public address. That change deserves a small release ritual: identify the version, prove its central journey, connect the real services and keep the last working copy available.

This guide is for a browser-based web app. A responsive site can work beautifully on a phone and may even be installable, but that is not the same as submitting a native iPhone or Android package to an app store. Treat store packaging, device permissions and store review as a later project if you need them.

Write these down before pressing Publish

Exact version

The revision or completed builder turn you are about to release.

Central journey

One sentence naming who does what and the saved result they should reach.

Connected services

Login, database, payments, email, uploads and anything else outside the page files.

Public routes

The home page plus every address people may bookmark, share or land on from search.

Rollback

The last known-good version and the person able to restore it.

1. Finish the edit, then freeze the release candidate

Let the current builder turn finish saving before you test. Read its changed-file receipt and open Preview from that completed state. If you make another tiny edit after testing—yes, even a heading—you now have a new release candidate and the affected checks need another pass.

Do not ask the agent for broad polishing while a release is already half-tested. Put new ideas in a short next-version list. The cleanest launch is not the version with the most last-minute activity; it is the version whose behaviour you can describe and reproduce.

2. Preview the whole journey at three sizes 📱

Use the Preview controls to check a 375px phone, a 768px tablet and a wide desktop. Start at the entry screen each time and complete the same journey. Do not stop after admiring the hero; most release problems live in a menu, long form, empty state or final confirmation further down the path.

Use deliberately long but fictional content. A generous service title, long customer name and useful error message reveal wrapping problems that tidy sample words hide. On the phone, open the menu, focus every field, close every dialog and reach the last action without content sliding under fixed controls.

1. Reload Preview and start from the intended public entry screen.
2. Complete the central journey at 375px with long fictional details.
3. Repeat at 768px where navigation and grids often change shape.
4. Repeat on a wide desktop using keyboard focus as well as a pointer.
5. Check loading, empty, invalid and successful states—not only the filled example state.
6. Record failures against the exact version rather than fixing from memory.

Tip. A page that merely has no horizontal scroll can still be miserable on mobile. Check reading order, tap comfort, keyboard space and whether the main action remains obvious after the layout stacks.

3. Prove saved data and access with fresh accounts

If the app promises accounts or saved information, create a fresh fictional account and complete the real save. Reload, sign out and sign back in. The record should remain when persistence is promised, and it should not appear to a second ordinary account simply because that person knows its address.

A working admin screen is not proof of safe permissions. Use at least two roles, try the direct link signed out and test an expired session. When the app cannot reach its database or authentication service, it should show a useful unavailable state instead of manufacturing success locally.

• A new account can enter and an existing account can return.
• A saved record survives reload when the interface says it was saved.
• Person B cannot view or edit Person A’s private record.
• Signing out removes access to protected routes and cached private content.
• A service failure is labelled failed or unavailable—never silently passed.

4. Move every integration to the public address

External services often trust named origins, callback URLs or webhook addresses. The preview address working does not prove the live one is allowed. Check login callbacks, payment return URLs, email links, storage rules and any provider dashboard that contains an allow-list.

Keep secret values in the protected environment or dashboard connection that owns them. A publish checklist can name an environment variable, but it should never contain the value. If a key was pasted into a prompt or client file during the build, rotate it before launch rather than assuming the final file is the only copy.

5. Publish first, connect the custom domain last

Use Grafter’s Publish control to put the tested version online, or export it if your plan and workflow call for external hosting. Open the resulting public address in a fresh tab—preferably a browser session that is not already signed into the builder—and perform the central journey one more time.

Visit every public route directly, including a nested page, instead of reaching it only through navigation. Refresh there. A route that works after clicking but becomes a 404 after reload needs hosting or routing attention before search engines and real people find it.

1. Press Publish and choose the route appropriate to your plan.
2. Wait for the completed public result rather than closing on the first progress message.
3. Open the public address in a fresh tab or signed-out browser session.
4. Complete the central journey and verify its saved or provider-side result.
5. Paste every important nested route directly into the address bar and reload it.
6. Check page title, description, share image, favicon and indexability on the public response.

Note. Publishing a broken route under a custom domain makes diagnosis harder because deployment, DNS and certificates change at once. Prove the host’s temporary public address first; then add the domain as its own controlled change.

6. Connect the domain without losing the old audience

Once the public copy works, connect the chosen domain and wait for HTTPS to become active. Pick one canonical form of the address and redirect alternatives to it. If an older site already ranked or had shared links, map each valuable old route to the closest new page instead of sending everything to the homepage.

Save the DNS records you changed and their previous values. DNS takes time to settle across networks, so keep the former service recoverable until real visits reach the new one. Confirm the sitemap and robots file use the final public host rather than a local, preview or temporary address.

• HTTPS works with no certificate warning.
• www and non-www resolve consistently, with one canonical address.
• Important old URLs have specific redirects rather than a blanket homepage jump.
• Authentication, payment and email callbacks include the final domain.
• Canonical links, sitemap URLs and social metadata use the final domain.

7. Watch the first journeys and keep the way back 👀

Run one real public journey yourself and then inspect the server, database or provider evidence that proves it. Watch uncaught errors, failed requests and broken assets during the first release window. A cheerful final screen cannot tell you that an email bounced or a payment event was never recorded.

Keep the previous deployment and data backup available. Decide in advance which hard failure pauses the feature or restores the last version: lost writes, exposed private data, false payment success and an unusable central journey are sensible examples. Rollback is a release feature, not an admission of defeat.

Common questions

How do I publish an app made with AI?

Finish one named version, test its central journey on phone, tablet and desktop, prove connected services, then publish and reopen the public address in a fresh session. Connect a custom domain only after that public copy works.

Is publishing a web app the same as putting it in an app store?

No. Web publishing creates a browser-accessible address. Apple App Store or Google Play submission needs a native package or suitable wrapper, store accounts, device testing, privacy information and store review.

Why does a page work when clicked but show 404 after refresh?

Client-side navigation can hide a missing host fallback. Test every public nested route by opening it directly and refreshing; configure the deployment to serve the app for valid routes before launch.

Should I connect my custom domain before testing?

No. First prove the hosted public address, routes, services and central journey. Add the domain afterwards so a deployment problem is not mixed together with DNS and certificate changes.