Taking a Lovable, Bolt or Replit App to Production: A Checklist

Updated October 2026 by the Cliffex team. Prices are in USD.

Short answer: to take a Lovable, Bolt or Replit app to production, keep a copy of the code in a repository you control, test who can access each record, keep secret keys on the server, verify payment events, and check backups, monitoring and release procedures. You can use the builder’s managed hosting if it meets your requirements; production readiness does not require moving hosts. AI builders get the screens and basic logic working fast, but security is the gap to check first: in Veracode’s 2025 GenAI Code Security Report, models introduced security flaws in 45% of test cases across 80 curated coding tasks. That is a result from a controlled study, not a failure rate for these builders or their current apps. At Cliffex, small fixes to an AI-built app are billed at $25 to $49 an hour with an estimate first, and a rebuild gets a fixed quote, usually within our $4,000 to $20,000+ app range.

FURTHER READING

> MVP Development Cost in 2026: Prices, Timelines and Examples

> Mobile App Security: OWASP Standards and Release Checklist 2026

> App Cost Calculator: Estimate Your App Project

What changes between a demo and a production app?

A demo has to work once, for you, on your screen. A production app has to work every day for people you have never met, some of whom will try things you did not plan for. The table shows checks to make before real users depend on an app.

Area	Works in the demo	Needed in production
Logins	You can sign up and sign in	Password reset, email verification, sessions that expire, and account deletion
Data access	You see your own data	Database rules that stop one user reading or editing another user’s data
Secrets	API keys work from the browser	Secret keys kept on the server and rotated if they were ever exposed
Payments	A test checkout succeeds	Orders confirmed by signed webhooks, duplicates ignored, refunds and failed payments handled
Data safety	Data is saved	Automatic backups, a tested restore, and separate test and live databases
Hosting	A preview link	Your own domain, accounts in your name, error alerts and someone watching them
Changes	Prompt, preview, publish	Version control, a staging copy and tests run before each release

What to test before real users arrive

A working demo does not show whether access controls, payment handling or recovery procedures work under less familiar conditions. Test these areas explicitly, including with separate user accounts.

• Database access rules. Lovable, and several other AI builders, use Supabase for the database. Supabase’s own row-level security guide warns that a table in an exposed schema without row-level security is readable and writable by any role with a grant on it. If the rules are missing or too loose, a user can read other people’s records straight from the browser.
• Keys in the wrong place. Keys for payment, email or AI services sometimes end up in front-end code, where anyone can copy them. Supabase’s guide says a secret key must never be used in the browser; distinguish secret or privileged keys from publishable keys designed for browser use. Public keys still need correctly configured access controls.
• Payments that look done but are not. A redirect to a thank-you page is not proof of payment. Stripe’s webhook documentation tells you to verify the signature on every event and to log event IDs so the same event is not processed twice. Check both in the actual implementation, including retries and events that arrive out of order.
• One database for everything. Testing new features against live customer data is how records get overwritten. Production needs a separate test environment.
• No backups or monitoring. If nobody gets an alert when the app errors, you hear about problems from customers.
• Fix loops. As the app grows, asking the AI to fix one bug can quietly break another feature. Without tests, nobody notices until a user does.

Our mobile app security guide covers the wider security checklist, including OWASP security guidance.

A production checklist for AI-built apps

Use this as a self-check before you invite paying customers. If you cannot answer yes to an item, that is the work still to do.

Check	What to look for	Why it matters
Code ownership	Code synced to a GitHub (or similar) repository under your account	You can hand it to any developer and roll back bad changes
Database rules	For Supabase, row-level security and appropriate grants on exposed tables; test signed-out access and separate users or roles. Other backends need equivalent server-side authorization	Restricts records to the users and roles allowed to access them
Secrets	No secret keys in front-end code; keys stored as server environment variables	Exposed keys can be used to run up bills or read data
Sign-in	Password reset, email verification and account deletion all work	For App Store apps that support account creation, Apple requires account deletion within the app
Payments	Webhook signatures verified; duplicate events ignored; failed payments handled	Orders and subscriptions match what was actually paid
Environments	Separate test and live databases and keys	New features can be tried without touching customer data
Backups	Automatic backups and one restore you have actually tested	A bad change or deletion can be undone
Monitoring	Error alerts and uptime checks that reach a person	You can detect and respond to problems promptly
Accounts	Domain, hosting, database, app store and payment accounts in the business’s name	The app stays yours if a freelancer or tool changes

How do I publish a Lovable app outside Lovable?

Lovable can host your app for you, and for an early product that may be enough. If you want your own hosting, Lovable’s self-hosting documentation (checked October 2026) says the app has three parts that can move separately: the code, the front end and the backend with its data. The main points:

• Code. Git sync keeps a copy of the code in a repository you control, and you can keep editing in Lovable while another host deploys from that repository.
• Front end. Older Lovable apps built with React and Vite produce static files that any static host can serve. Apps created on the TanStack Start setup from May 13, 2026 run server code, so the host has to support that.
• Backend and data. The exported code includes database migration files but not the data or uploaded files, which you export separately. Lovable’s backend can move to managed or self-hosted Supabase; moving only the Postgres database leaves authentication, storage and functions behind.
• Settings. On the new host you set environment variables, server secrets and sign-in redirect URLs yourself.

Bolt, Replit and most other AI builders also let you download the code or sync it to GitHub. The export options differ by tool and change often, so check the current documentation before you plan a move.

Can you publish a Lovable or Bolt app to the App Store?

The route depends on what you built. Lovable produces web apps; a mobile version may use a native shell or a separately built mobile interface. Bolt supports Expo-based mobile projects, and Replit supports React Native and Expo apps with an iOS submission workflow. Check the project type before assuming a rebuild is needed. Replit’s current documentation says its Google Play publishing workflow is not yet supported, even though Android development and previews are available.

A thin wrapper is risky with Apple. Guideline 4.2 of the App Store Review Guidelines asks for an app that goes “beyond a repackaged website”, and guideline 5.1.1(v) requires in-app account deletion if users can create accounts. We explain what reviewers look for in our post on WebView apps and App Store rejection. If the app relies on device features or in-app purchases, budget for platform integration, real-device testing and the applicable store requirements. A wrapper does not guarantee approval.

Should you build on your AI-built app or start fresh?

There is no fixed answer. What decides it is how much of the existing code a developer can trust. This is how we usually make the call:

Build on what you have when	Rebuild when
The data model makes sense and matches how the business works	Data is duplicated across tables or stored in ways that cannot be secured
Fixes are mostly security rules, payments and hosting	Every fix breaks something else and there are no tests to catch it
It is a web app and will stay a web app	The current interface cannot meet the required mobile experience; assess a new mobile front end while retaining a suitable backend
The code is in a repository with a readable history	The code cannot be exported, or nobody can explain how it fits together

Even when we rebuild, the AI-built version is useful. It works as a clickable specification that shows exactly what you want, which shortens planning. For more on choosing a backend for the rebuild, see BaaS vs a custom backend.

What does it cost to take an AI-built app to production?

It depends on how far the app is from the checklist above. These are Cliffex’s published prices; we look at the app first, and you get an estimate or a written quote before any work starts.

Situation	How it is priced at Cliffex	Cliffex planning range
Small fixes: database rules, secrets, payments, hosting setup	Hourly, with an estimate first	$25 to $49 an hour
Rebuild as a focused first version	Fixed quote	$4,000 to $10,000
Rebuild as a business app with several user roles, or iOS and Android plus an admin	Fixed quote	$10,000 to $20,000
Platform with many integrations or several connected apps	Fixed quote, often in phases	$20,000+
After launch	30 days of support included, then hourly	$25 to $49 an hour

Your quote is your price unless the scope changes. Running costs such as hosting, the database plan and app store fees are separate and paid to those providers. See our pricing page for what each tier includes and our app maintenance guide for costs after launch.

How to get an accurate quote

1. Share a link to the app or a few screenshots, and say who uses it today.
2. If you can, sync the code to GitHub and give read-only access.
3. List what does not work yet, in plain words, such as “customers can’t pay” or “I’m not sure who can see what”.
4. Say whether you need iOS and Android apps or a web app is enough.
5. Tell us your launch date and anything that cannot change.

For a quick range, describe the app in our app cost calculator. To have us look at what you built, see AI-built app development or send us your project.

Frequently asked questions

Can you actually build a real app with Lovable?

Yes. Lovable and similar tools can build working web apps with logins, a database and payments. Before launch, verify security rules, payment handling, testing and long-term upkeep using the checklist above.

Is Lovable good for production apps?

It can be, for simpler web apps, once the database rules, secrets, payments, backups and monitoring have been checked. Apps that handle sensitive data, complex business logic or high traffic need a developer to review and test the code before launch.

How do I publish my Lovable app?

Lovable can publish to its own hosting. To use your own, sync the code to GitHub, deploy it to a host of your choice, set the environment variables and redirect URLs, and decide whether the backend stays with Lovable or moves to your own Supabase project.

Can you publish Lovable apps to the App Store?

Not directly, because Lovable builds web apps. You need a native wrapper or a cross-platform rebuild, and a thin wrapper of a website risks rejection under Apple’s guideline 4.2.

How much does it cost to make an app on Lovable?

Lovable’s own subscription prices are listed on its website. Taking the result to production is a separate cost: at Cliffex, fixes are billed at $25 to $49 an hour with an estimate first, and rebuilds start at $4,000 with a fixed quote.

Who owns the code and data?

Keep the repository, hosting, database, domain and app store accounts under your business’s control. Lovable’s documentation says you own what you create, subject to third-party rights such as open-source licences. Exportability is separate from legal ownership: check tool terms, component licences and any development contract, and verify that exported data and services work at the destination.