Lovable or Bolt prototype to production: a checklist
To take a Lovable or Bolt prototype to production, check six areas in this order: access to data, secret keys, payments, reliability, code health and legal requirements. This checklist gives you 22 concrete checks you can run yourself, the order to fix them in, and an honest split between what you can do alone and what needs an engineer.
By cklicky.com · Published · Updated
How to use this checklist
A prototype built with Lovable, Bolt or a similar AI builder can become a real product. What separates the two is a known list of work, and this is that list. Go through it with your app and your database dashboard open. Mark each item "yes", "no" or "not sure"; treat "not sure" as "no".
Why these gaps appear in AI-built apps at all is explained in is AI-generated code secure?. You can check almost everything here without being a developer. Fixing is a different matter, and the last section says which fixes are safe to try yourself.
1. Access and data
This group matters most, because mistakes here expose other people's data.
- Each user can open only their own records. Log in as one user, copy the address of a record, then log in as another user and open that address. You should see an error.
- Every table has access rules. In a Supabase project, Row Level Security should be on for each table. Supabase's guidance is to enable RLS on every table in an exposed schema.
- No rule allows everything. A policy whose condition is simply "true" protects nothing. Read each policy and ask who it lets in.
- Admin pages check the role on the server. Hiding the menu item is not enough. Open the admin address directly while logged in as a normal user.
- Uploaded files are not public by default. Open a file link in a private browser window. Private documents should not load.
Broken access control is the first item in the OWASP Top 10 for 2025, and the first item of the OWASP API Security Top 10 is the same problem at the level of single records.
2. Secrets and keys
- No secret key is in the frontend code. Search the code and the built files for "secret", "service_role" and "sk_live". A Supabase secret key bypasses every Row Level Security policy, so it must exist only on a server.
- Keys are not in the repository history. Deleting a key from a file does not remove it from earlier commits. A key that was ever committed should be replaced.
- AI and payment provider keys have spending limits. Set a monthly limit in each provider's dashboard, so a leak or a bug cannot run up an unlimited bill.
3. Payments
- Orders are fulfilled from a webhook. Stripe says you cannot rely on the landing page alone. Test it: pay, then close the tab before the success page appears.
- Webhook signatures are verified. Stripe signs every event so you can confirm it was not sent or changed by someone else.
- Prices are set on the server. If the amount is sent from the browser, a user can change it. The server should look the price up itself.
4. Reliability
- There is a backup, and you have restored from it once. An untested backup is a hope, not a backup.
- Errors reach you. Break something on purpose. If you only find out when a user writes, add error monitoring.
- There is a staging copy. Changes should be tried somewhere other than the live product first.
- A release can be undone. Ask yourself how you would return to yesterday's version in five minutes.
5. Code health
- The code is in a repository you own. Not only inside the builder. This is what lets anyone else work on it.
- Database changes are stored as migrations. Otherwise the database cannot be rebuilt or copied safely.
- The critical paths have automated tests. At least sign-up, payment and the main action of the product.
- A new developer could set it up from the README. If setup lives only in your memory, write it down now.
6. Legal and store requirements
- There is a privacy policy that matches what the app really does. List every outside service that receives user data.
- Users can delete their account. For iOS apps this is a rule: Apple's App Review Guidelines (5.1.1(v)) require in-app account deletion when the app supports account creation.
- The Google Play Data safety form is complete. Google requires it for every published app, including apps that collect nothing.
If you plan a mobile release, see what else the stores ask for on our AI mobile app development page.
What to fix first
- Exposed data and secret keys. Fix these before anyone else uses the product, and replace any key that was exposed.
- Payments. Money that is taken but not recorded, or goods given without payment, destroy trust fastest.
- Backups and monitoring. So the next problem is recoverable and visible.
- Tests and migrations. So fixing one thing stops breaking another.
- Everything else. Tidiness, speed and nice-to-haves come last.
What you can fix yourself, and what needs an engineer
| Usually safe to do yourself | Better done by an engineer |
|---|---|
| Turning on spending limits and replacing exposed keys | Writing access rules for tables that hold personal data |
| Setting up error monitoring and scheduled backups | Moving business logic and secrets from the browser to a server |
| Writing the README and the list of what the product must do | Payment webhooks and anything that touches money |
| Adding a privacy policy and an account deletion request path | Database migrations on a system that already has users |
The right-hand column is where a small mistake has a large cost, and it is the work we do when we fix a vibe coded app. Much of it is server-side, which our backend development services page explains. If you want a second pair of eyes on your results, send them through the contact form.
Sources
Every external claim in this article links to its source. Checked in November 2026.