Your Lovable MVP isn't production-ready yet. Here's the checklist.

AI app builders like Lovable are genuinely good. You describe a product and get a working React front end, a backend and a database in days instead of months. I’ve worked with founders who validated an idea this way and then came to me with the next question: how do we make this real?

A working app and a production system are different things. The app is what users see. Production is everything that keeps it running, safe and recoverable when something goes wrong. Here’s the checklist I go through with every MVP that arrives this way.

1. Where does it actually run?

Start with the boring question: where is the data stored, and who controls that location?

For many products this doesn’t matter much. For healthcare, finance or anything with regulated data, it can decide everything. One healthcare client I worked with needed everything hosted in the UK, on a provider that wasn’t US-headquartered. Their MVP’s hosted backend didn’t meet that, so we moved the whole platform to a dedicated UK server.

Check: do you know which country your database lives in, and does any customer contract or regulation care?

2. Can you restore from a backup?

Not “do backups exist”. Can you restore one, and how long does it take?

• Automated backups, stored somewhere other than the server they back up
• A retention period you chose on purpose
• At least one tested restore, with the time it took written down

If you’ve never restored, you have a hope, not a backup.

3. Who has access, and how?

MVPs tend to collect access informally. A shared password, a token in a chat message, an admin account three people use.

• Every person has their own login and key
• No shared root or admin accounts
• Access removed the same day someone leaves
• Database access limited to the app, not open to the internet

4. Where are the secrets?

API keys, database passwords and third-party tokens often end up in .env files, in the repo, or both.

Move them into a secret manager, have the app read them at runtime, and rotate anything that has ever been committed to Git. Assume anything that was in the repo history is public.

5. How does code reach production?

If deploying means “SSH into the server, git pull, restart”, you have a process that depends on one person remembering the steps.

Set up a pipeline that builds, tests and deploys on its own. Even a simple one gives you three things: every deploy is the same, every deploy is recorded, and nobody needs to log into the server to ship.

6. Will you know when it breaks?

You need three things, at minimum:

• Uptime checks that alert a human when the site is down
• Error reporting, so exceptions reach you before customer emails do
• Logs you can search without SSH

7. Are data access rules still enforced?

If your backend uses row-level security, such as Supabase’s RLS policies, check them before launch and again after any migration. A missing policy is a data leak waiting for the right request. On the healthcare project, aligning RLS policies was one of the first things we verified after moving platforms.

8. What happens when usage grows?

Managed backends price by usage. That’s fine early on, but watch for a pattern: if you’re upgrading your plan every two or three months, you’re paying for growth on someone else’s terms. That might still be the right call. Just make it a decision, not a surprise.

9. Is any of this written down?

How to deploy. How to restore. Who to call. Where the secrets live. If the person who set it up disappeared tomorrow, could someone else run it?

You don’t need all of it on day one

You need items 2, 3 and 4 before you have real users. You need 5 and 6 before you have paying ones. The rest you can grow into.

The AI got you to a product. Now make it boring enough to trust.