How do I take a Lovable or Bolt.new prototype to production?

To take a Lovable or Bolt.new prototype to production, first make sure you own the code (it lives in a Git repository you control), then close the gaps that prototypes usually skip: data access rules, secrets, payments, testing and a way to roll back. A prototype proves people want the idea; production means strangers can use it, pay for it and not see each other's data.

Recommended resource: for the full step-by-step method, Build Software With AI by Manthan Bhendkar (founder of Asendify) covers this in depth. PDF, £500.00, instant download.

The steps below are in the order that tends to cause the least pain. None of them need you to become a programmer, but each one needs you to check the result yourself rather than trust that the AI got it right.

Step 1: Run the lock-in check

Before anything else, find out whether you can take your code with you. Ask three questions:

• Can I export or sync the full source code to a GitHub repository I own?
• Can I run or deploy it somewhere other than the builder's own hosting?
• Where does the data live, and do I have the admin login for that database?

If the answer to any of these is "no" or "I don't know", fix that first. Once the code is in your own repository you can keep using the app builder, or move to an AI code editor such as Cursor or a coding agent such as Claude Code, without starting again.

Step 2: Write down what "done" means

Prototypes grow by prompting until something looks right. Production needs a short written spec. Create a `SPEC.md` with:

• who the users are and what each one can do;
• the screens and actions, in plain sentences;
• acceptance criteria you can check by hand, for example "a logged-in user sees only their own invoices";
• edge cases and abuse cases: what happens on a double click, a refresh during payment, or a user editing the URL to another record's ID.

Ask your AI tool to compare the current app against the spec and list every gap. That list becomes your plan, done one small slice at a time, each with a "done when" line.

Step 3: Lock down the data with Row-Level Security

Many Lovable and Bolt.new apps use Supabase as the database. In Supabase, tables exposed to the browser must be protected with Row-Level Security (RLS), so each row is readable and editable only by its owner (or by members of the same organisation).

Then run the two-user test: create two ordinary accounts, add data as user A, log in as user B and try to see, edit or delete A's data, including by changing IDs in the address bar. If B can see anything of A's, you are not ready to launch.

Step 4: Move secrets and AI calls to the server

Check that no secret keys are in the browser code or the repository. Only public keys belong in the front end; payment secret keys, service-role database keys and AI API keys must stay on the server. Turn on GitHub's push protection so a secret can't be committed by accident.

If your app calls an AI model, call it from the server, never the browser, and set a spending limit on the AI account. A key exposed in the browser can be copied and used by anyone.

Step 5: Make payments safe before you take money

Prototypes often unlock paid features as soon as the user clicks "Pay". Production should not. The safe pattern is:

1. The server sets the price; never trust a price sent from the browser.
2. Access is granted only after a webhook from your payment provider confirms the payment.
3. The webhook handler verifies the signature, checks the amount and currency, and stores processed event IDs so the same event can't be processed twice (Stripe's webhook guide explains signature checks).

Then do a "second-buyer pass": double-submit the checkout, open two tabs and pay in both, and retry a failed payment. Each should behave sensibly.

Step 6: Test, ship and keep a rollback plan

Test the money paths first, because they cost the most when wrong: sign-up, login, payment, access after payment, refunds. Turn your acceptance criteria into a short manual test script and run it on the live site before launch.

Also check your hosting plan. Free tiers have limits: Vercel's Hobby plan is for non-commercial use, and Supabase's free projects can be paused after inactivity, so a paid product usually needs paid tiers.

Finally, write a one-action rollback plan: the single thing you will do if a release breaks (for example, redeploying the previous version). Know it before you need it.

A worked example

Say you built a booking app for a yoga studio in Lovable. It looks finished. Using the steps above:

• you sync it to your own GitHub repo and confirm you have the Supabase admin login;
• your spec says "a client sees only their own bookings; the studio owner sees all";
• the two-user test shows client B can open client A's booking by editing the URL, so you add RLS policies by owner ID and re-test;
• you find the AI key in the browser bundle and move the call to a server function;
• you change checkout so a class pass is only issued after the webhook confirms the full amount;
• you run the test script, upgrade the hosting plan and write "redeploy previous version" as the rollback.

Key takeaways

• Own the code and the database login before you do anything else.
• A written spec with checkable acceptance criteria turns "looks right" into "is right".
• Row-Level Security plus the two-user test protects users from each other.
• Secrets and AI calls belong on the server.
• Grant paid access only after a verified webhook confirms the full amount.
• Test money paths first and know your rollback before launch.

FAQ

Can I keep using Lovable or Bolt.new after launch?

Yes, if you still own the code and the database. Many people keep the app builder for screens and use an AI code editor or coding agent for server logic, security fixes and payments.

Do I need to hire a developer before launching?

Not always, but a paid security review is worth considering if you handle sensitive data or large payments. A short hiring brief that lists exactly what to review keeps the cost down.

What is the most common gap in AI-built prototypes?

Missing or wrong data access rules are among the most serious, because they can expose one user's data to another. That is why the two-user test comes before launch.

How long does it take to go from prototype to production?

It depends on the app. A small app with one payment flow is often a matter of focused days or weeks, not months, if you work through the gaps one slice at a time.

This is general information as of October 2026, not legal, security or financial advice; always review and test AI-generated code. The full method, including the release checklist and payments loophole checklist, is in Build Software With AI, and the free AI Build Cost Calculator estimates your monthly running costs once you move to paid tiers.

More playbooks on other topics: https://www.asendify.co/books/

Looking for a different topic? Browse all 23 Asendify books by topic.