How to Turn Your AI-Built Prototype Into a Real App

Do it in this order: get the code and data somewhere you control, lock down who can read and write the database, separate a development copy from production, set up backups you have actually restored, check that your free tiers allow commercial use and won't pause, then switch payments, auth and email from test settings to live ones. The interface you built usually survives as it is. What changes is everything around it.

Our earlier guide, Taking a Vibe-Coded Prototype to Production, compares the services you might add (auth providers, databases, hosts, monitoring). This one is the step-by-step checklist for the move itself, with what to check in each tool.

Before real users depend on the app, make sure you own a copy of it that works without the builder. If the builder has an outage, changes its pricing, or you need a developer's help, this is what you will hand over.

• Code: connect the project to GitHub. In Lovable, GitHub sync is available on all plans, including Free, and syncs both ways for one branch. On paid plans you can also download the codebase as a zip.
• Data: code exports don't include your records. Lovable's docs say Git sync and the codebase download include neither the records in your database nor the files in storage, and its database export does not include stored files, Edge Function code, or secrets.
• Secrets: API keys and environment variables are not in the repository either. Keep your own list of every key the app uses, which service it belongs to, and where to regenerate it.

If you built on Base44, Replit or another platform that runs the backend for you, find out the same three things: can the code leave, can the data leave, and what stays behind.

Go through the app as a stranger would and list everything that relies on being a demo. Common items:

• Sample or seed data mixed in with real records, and test accounts with simple passwords.
• Pages that hide buttons in the interface but don't check permissions on the server. Hiding an admin link is not access control.
• Features that call an AI or paid API from the browser with a key in the frontend code.
• Forms with no validation or size limits, so one user can paste megabytes into a field.
• Flows you never tested end to end: password reset, email change, account deletion, a failed payment, a cancelled subscription.
• No terms of service or privacy policy yet.

Put this list in a document and work through it. Ask the AI to help with each item, but test each one yourself in a private browser window, signed in as a normal user.

This is the step that matters most, because a prototype database is often readable by anyone who opens the browser's developer tools.

If you use Supabase, the browser talks to the database with a publishable (anon) key. Supabase's docs say that key is safe to expose only as long as Row Level Security is enabled, and that a secret key bypasses every policy and must never be in a browser, a shipped app, or source control. They also warn that a table in an exposed schema without RLS is readable and writable by any role with a grant on it, and that a policy using to anon using (true) gives every visitor read access.

What to do:

• Enable RLS on every table, then write policies for who can select, insert, update and delete. A typical rule: users can only touch rows where user_id = auth.uid().
• Test the policies by signing in as two different users and trying to load the other user's data.
• Search the code for secret keys. Anything in a variable that starts with VITE_ or NEXT_PUBLIC_ ends up in the browser; Vite's docs say VITE_ variables "should not contain sensitive information such as API keys". Move secret calls into an edge function or server route.
• In Lovable, run the security scan. The automatic quick scan at publish checks database rules and dependencies; the deep scan, which you start yourself, also reviews application code for problems such as unauthenticated endpoints and leaked secrets. Lovable states its tools cannot guarantee complete security, so for apps with sensitive data a professional review is still worth it.

In a prototype, you and the AI edit the same app that users see. In a real app, changes are tried somewhere else first.

• Database: Replit already works this way. It keeps separate development and production databases, its Agent cannot modify the production database, and schema changes made in development are applied to production when you publish. Its docs flag risky changes to watch for at publish: dropping columns or tables that still hold data, changing column types, adding required fields without defaults to tables with rows, and renaming tables or columns. Those risks apply to any stack. With Supabase, a common setup is a second project for development.
• Hosting: on Vercel, every branch that isn't the production branch gets its own preview deployment, and you can scope environment variables to Production, Preview or Development. Point previews at the development database and test keys, and only Production at the real ones. Remember that variable changes only apply to new deployments.
• Payments: Stripe sandboxes and live mode have separate API keys, and objects in one are not accessible to the other. Test with sandbox keys everywhere except production.

Then make one rule for yourself: no AI edits go straight to production. Edit, test the preview, then publish.

Check what your database plan actually backs up. Supabase backs up Pro, Team and Enterprise projects daily, and Pro projects can access the last 7 days. Free projects get no automatic backups, and the docs recommend exporting your data regularly with the Supabase CLI's db dump command and keeping the copy somewhere else. On Replit, an Agent rollback does not restore production databases; those use point-in-time restore, so check those options separately.

A backup you have never restored is a guess. Once, before launch, restore your latest backup into a fresh development project and check that the app runs against it. Note how long it took. That is your real recovery time if something goes wrong.

Back up uploaded files on their own as well. Lovable's docs, for example, note that its database export does not include stored files.

Free plans are built for trying things, and some of their rules make them unsuitable for a product with customers.

• Vercel Hobby is free, and its docs say it restricts users to non-commercial, personal use only. If the app takes money or promotes a business, plan for Pro.
• Supabase Free projects pause after a week of low activity, are limited to 500 MB of database per project and 2 active projects, and have no daily backups. Pro starts at $25 a month and is not paused for inactivity.
• Supabase's built-in email only sends to your own team and is limited to 2 messages per hour, so it cannot send sign-up emails to real users. Set up a custom SMTP provider.
• Builder credits may matter at runtime too. Lovable's docs say that when credits run out, AI features in deployed apps stop working and apps on its Cloud backend pause.

Add up the monthly cost of the plans you actually need. If the total is more than the app will earn soon, that is useful to know before launch, not after. Our pricing page lists current builder plans.

On launch day, these are the settings that most often still point at the prototype:

• Auth Site URL and redirect URLs. Supabase's Site URL starts as http://localhost:3000 and is used for email confirmations and password resets. Set it to your real domain, add exact production redirect URLs, and add the new domain to any Google or GitHub OAuth app.
• Stripe live keys. Replace pk_test_ with pk_live_ in the frontend and the server key with a live one, kept on the server. Stripe recommends restricted keys with only the permissions you need over an unrestricted secret key.
• Stripe webhooks. Each endpoint has its own signing secret, and if the same endpoint is used for test and live, the secret is different for each. Create the live endpoint, copy its secret into production, and send a test event. Your handler should verify the signature using the raw request body and handle the same event arriving twice.
• Email sender. Confirm sign-up, reset and receipt emails arrive from your domain and don't land in spam.

Then sign up as a brand-new user on the live site, pay with a real card, refund yourself, and reset your password. If all of that works, you are ready for real users.

Not necessarily. Many apps run in production on the builder's own hosting, and keeping it means you keep the visual editor. Leave when you need something the platform can't give you: a specific host or region, server code the builder doesn't support, or control over every change.

If you do move, Lovable's external hosting guide lists what catches people out, and most of it applies to other builders too:

• Environment variables and secrets are not in the repository; set them on the new host.
• Older React and Vite apps need the host to serve index.html for unmatched routes, while TanStack Start apps need a host that runs the server.
• Apply database migrations in their recorded order, test a restore on the new project first, and keep the app on the old backend until the new one is complete.
• Edge Functions deploy separately with the Supabase CLI, and scheduled jobs don't carry over, so recreate them.
• Add the new production URL to your auth redirect list. Users have to sign in again because sessions don't move.
• Pause writes, take a final export, restore it, then switch, since anything written after your last export is lost.

For the editor side of the move, see our Cursor setup guide.