The complete guide

How to ship an app you built with an AI coding tool

Getting an AI-built app in front of real users takes six steps: find out what is exposed, fix access to your data, make authentication real, deploy somewhere you control, handle failure, and decide what is worth paying someone else to do. Most of the checks take minutes. The fixes are where the time goes.

This is the whole path in one place, written for someone who built something with Lovable, Bolt, Replit Agent, v0, Cursor or Claude Code and now has to make it real. Each step links to a longer piece if you want the detail.

One thing to get out of the way first: if several of these checks fail on your app, that is normal. These tools stop at the same boundary every time, because generating a working demo and configuring a system strangers can use are different problems, and only the first one is automated.

What “done” actually means

An app is finished demoing when it works while you show it. It is ready for other people when four things are true, and none of them is visible from the outside:

  • Someone who signs up cannot reach anyone else’s data, even if they go looking.
  • Nothing secret is readable in the browser.
  • It runs on infrastructure you control, and you can deploy a change without ceremony.
  • When something fails, the user sees something useful and you find out it happened.

Everything below is in service of those four.

Step 1: Find out what is exposed

Start here, because it takes a minute and because it is the one where being wrong is hardest to undo. Anything your front-end can read, a visitor can read. Open your live site, press F12, and search the loaded JavaScript for sk_, secret and service_role.

Any match is not “potentially exposed” — it is published, to everyone who has ever loaded your site, and it needs rotating rather than merely moving.

Read next: Your API keys might be in the browser. Here is how to check in 60 seconds

Step 2: Fix access to your data

This is the step that matters most and the one most often skipped, because nothing visibly breaks when you skip it. Supabase ships new tables with Row Level Security disabled. Firebase has an equivalent default. Your app works perfectly without access rules — right up until someone looks.

Two things to check, in order: that RLS is enabled on every table holding anything real, and that each policy checks ownership rather than merely that the user is signed in. The second is the one that catches people out, because a table with a policy reads as protected while still letting every signed-up user read every other user’s records.

Read next: Are Lovable apps secure? What the tool does and does not do for you

Step 3: Make authentication real

A login screen and authentication are not the same thing. AI tools generate the screen reliably and the enforcement rarely. The pattern to look for: the interface decides what to show based on a value held in the browser, and the server never re-checks it when the data is requested.

The two tests that settle it, both under a minute:

  1. Log out, then paste a logged-in URL into a private window. If it loads, your routes are not protected on the server.
  2. Sign up as a second user and change an ID in the URL to point at the first user’s record. If you can see it, your permissions live only in the interface.

Step 4: Deploy somewhere you control

Every one of these tools has a hosted preview that supplies things your own host will not: environment variables, a database connection, an installed build environment. That is why the first real deploy fails, and why the failure looks like a code problem when it usually is not.

Read the build log rather than the page. A blank screen tells you nothing; the log tells you whether the app failed to compile or failed to start, and those have different fixes.

Read next: Why your Lovable app works locally but fails in production

Step 5: Handle failure

The step everyone leaves out, because while you are the only user nothing fails. Three things, none of them large:

  • A failed request shows the user something rather than a blank screen. AI tools generate the happy path and almost never the error state.
  • Errors are recorded somewhere you will actually look, rather than in a console nobody has open.
  • You have a database backup, and you have restored from it once to confirm it works. A backup you have never restored is an assumption, not a backup.

Step 6: Decide what to pay someone else to do

Some of this you can do yourself in an afternoon. Some of it — restructuring a data model that never represented ownership, or moving secrets to server-side functions without breaking the app — is genuinely harder than it looks.

The honest first step is finding out which of those you are facing before committing to anything. What drives the price is not how big the app is but how much of it is broken rather than merely insecure, and whether the data model survives.

Read next: What it costs to make an AI-built app production-ready

Does it matter which tool you used?

Less than people expect. All of them leave the same four things undone: access rules, server-side permission checks, secrets that are not the intended public ones, and deployment you control. Rebuilding the same app in a different tool produces the same gaps plus the cost of the rebuild.

The one real difference is how much they assume you know. v0, Cursor and Claude Code give you the most freedom, which means the gaps land wherever your own knowledge ran out. Lovable and Bolt assume less, so there are fewer ways to go wrong without noticing.

Read next: Lovable vs Bolt vs Replit Agent vs v0: what each one leaves you to finish

Or have someone else go through it

Send us the repo or the live URL. You get a written list of what is broken, what each fix costs and what can wait — back within 24 hours, and yours to keep whether or not you hire us.

Get a $99 audit