Lovable App to Production: A Developer Handoff Checklist

A Lovable app is ready for real users when its important flows work under real conditions and someone other than the original builder can run it. Treat the code repository, database rules, secrets, payments, testing, deployment, and recovery as separate sign-off areas. Some can be finished inside Lovable. Others may need changes to hosting, infrastructure, or code.

Key takeaways

• Sync the project to a GitHub repository you own before anyone else touches the code.
• Lovable's version history restores code but doesn't roll back database data. Plan backups separately.
• With your own Stripe key, Lovable doesn't set up webhooks by default, and a live key in the preview charges real cards.
• Leaving Lovable hosting is possible. The export doesn't include database rows or stored files, and the backend can move only to Supabase.
• The handoff table below gives each area an owner and a clear definition of done.

What counts as production

For a Lovable app, production means a stranger can sign up, complete the main task, pay if needed, and come back later to find their data intact, while no other customer can see it. It also means you can release a change, notice when something breaks, and undo it.

Write down the three to five journeys that matter most before the handoff starts. "A customer books a slot, pays a deposit, and receives a confirmation email" gives a developer something to test. "Make it production ready" doesn't. The AI prototype to production guide has a general readiness matrix if you want to start broader.

GitHub handoff

Lovable's GitHub integration gives a developer the full source code and its history. A few details shape how the handoff works:

• Sync creates a new private repository. You can't connect an existing one, so connect it to your own GitHub account or organization.
• Lovable edits a single branch. When local changes and Lovable changes diverge, Lovable pushes to a separate lovable-sync branch that someone has to merge.
• Changes made in Lovable are committed by lovable-dev[bot], so the history shows prompts as bot commits.
• GitHub rejects files over 100 MB, and Lovable can't edit files over 10 MB.
• Deleting the repository or transferring the workspace breaks the sync.
• Only workspace owners and admins can manage the connection.

Invite the developer to the repository through GitHub rather than sharing your Lovable login. Agree early on which parts you'll keep changing with prompts and which should change only through code review.

Database and access rules

Lovable apps typically read and write the database from the browser, which is safe only when row level security policies limit each user to their own rows. Check that every table with customer data has row level security enabled and a policy for each action the app uses. Then test with two accounts: as the second account, try to open, edit, and delete the first account's records. Every attempt should fail.

Server functions that use the service role key skip those policies, so each one needs its own check of who is calling. The vibe coding security checklist has a risk-ranked set of tests for this.

Back up the data before larger changes. Reverting in Lovable's version history restores code and redeploys edge functions, but it doesn't roll back database data. A schema change that a later revert leaves in place can break the older code.

Stripe and webhooks

Lovable offers two payment setups, and they behave differently. Its built-in payments, available on Pro plans and above, include separate test and live environments. If you connect your own Stripe key instead, Lovable's Stripe documentation explains that it checks payment status with Stripe directly, matches subscriptions to customers by email, and doesn't set up webhooks by default.

Before launch with your own key:

• Confirm the preview uses a test key. In this setup the preview has no separate test environment, so a live key there charges real cards.
• Use a restricted key with only the permissions the app needs, stored in Lovable's Secrets, and never pasted into the chat.
• Add verified webhooks for renewals, failed payments, refunds, and cancellations, and process each event once.
• Remember that matching by email breaks when a customer changes their email address. Store the Stripe customer ID on the account.
• Test the customer portal on the published app, because it doesn't work in the preview.

Stripe's testing documentation lists test card numbers, including ones that simulate declines and authentication.

Email and other external services

Most apps send email: confirmations, password resets, receipts. Use a sending provider with your own domain, and set up the domain's SPF, DKIM, and DMARC records so messages reach the inbox. Test every email the app sends, including password reset, on a fresh account.

List every other service the app calls, such as AI models, maps, file storage, or a CRM. For each one, note whose account it runs on, where the key is stored, and what the user sees when the service is down. If the app uses connectors or AI calls that run through Lovable, those need replacing with your own accounts if you later leave Lovable hosting.

Security and QA

Lovable runs a quick security scan on every publish and offers a deeper scan on request. Fix what they find, then go further, because the scans don't test your business rules. Run the main journeys on a phone and a laptop, in a private window, with new accounts. Try each admin URL as a regular user. Search the loaded JavaScript in your browser's developer tools for any private key.

Lovable also supports browser tests, frontend tests, and tests for edge functions. Ask for tests that cover sign-in, the main journeys, and payment handling, so later prompts can't quietly break them.

Environments and deployment

The Publish button publishes to Lovable hosting. If you want to host elsewhere, Lovable's external deployment guide explains what each stack needs:

• Check package.json for @tanstack/react-start. If it's there, the app is TanStack Start and needs a host that runs server code. Projects created since May 13, 2026 use this stack.
• Older apps are React and Vite builds that output static files to dist/. The host must send every path to index.html, or deep links will 404 on refresh.
• The code export doesn't include database rows or stored files.
• Moving the backend off Lovable Cloud is supported only to Supabase, managed or self-hosted. The database schema and storage buckets come across through migrations. Auth providers, secrets, table data, stored files, and user accounts need manual steps.

Before switching traffic, test deep links on refresh, sign-in and sign-out redirect URLs, reads, writes, uploads, and every server function on the new host.

Monitoring and rollback

Set up error reporting that alerts a person, uptime checks on the main pages, and a view of failed payments and failed emails. Write down how to roll back: in Lovable, restore an earlier version from history or a bookmark, and restore the database from backup if the data changed too. Practice once before launch.

Handoff to ongoing maintainers

Use this table to agree on what each person owns at handoff. Fill in names, and don't mark a row done until its "done when" condition is met.

Ongoing maintenance also needs a support path. Decide who answers customer issues, how quickly, and how urgent fixes reach production. If you plan to hire for this, the guide to hiring a developer to finish an AI-built website covers what to send and how to compare proposals. Routeless also offers Lovable development help, and the Lovable SEO guide covers search visibility after launch.

Frequently asked questions

Can you deploy Lovable outside Lovable?

Yes. You can export or sync the code and host it yourself. TanStack Start apps need a host that runs server code, and older React and Vite apps need every path routed to index.html. The export doesn't include database rows or stored files, and the Lovable editor itself can't be self-hosted.

What if I already have customers?

Back up the database first, then make changes in a separate test environment with test data and test payment keys. Test each change with accounts at different roles before releasing it. Plan releases for quiet hours, keep rollback steps ready, and tell customers ahead of any change to sign-in or billing.