The production checklist for Lovable apps: 15 things to fix before real users arrive

You vibe-coded something real with Lovable, Bolt, or Claude Code, and now people are actually using it. That’s a different job than building it. Production doesn’t care how the code was written; it only cares whether the basics hold. This is the same 15-point checklist we run on every free audit, so you can run it yourself first.

We built this list from the same pattern we see over and over in rescue work: a founder ships fast, the app works, and then one small thing (a leaked key, a backup nobody tested, an admin page nobody locked down) turns into the incident that costs a weekend or a customer’s trust. None of these 15 things are exotic. All of them are common, and all of them are fixable in an afternoon if you catch them before someone else does.

Every check below is something you can run against your own app, right now, in a few minutes each. Nothing here needs anyone’s permission but yours.

1. Frontend-bundle secrets

Open your site, view the page source, and list every <script src>. Fetch each one and grep it for key-shaped strings:

curl -s https://your-app.example.com/assets/index.js | grep -Eo "(sk_live_|service_role|SUPABASE_SERVICE|AIza|AKIA)[A-Za-z0-9_-]+"

If anything comes back, a database or payment key is sitting in code anyone can read. Rotate it today.

2. CORS

curl -s -i -H "Origin: https://evil.example" https://your-api.example.com/api/some-endpoint | grep -i "access-control-allow"

If you see Access-Control-Allow-Origin: * alongside Access-Control-Allow-Credentials: true, any website can make authenticated requests to your API on a logged-in user’s behalf.

3. Rate limiting

Send a small burst of requests at your login endpoint (10–15, no more):

for i in $(seq 1 12); do curl -s -o /dev/null -w "%{http_code}\n" -X POST https://your-app.example.com/api/login -d '{}'; done

If all 12 come back normal with no 429 or Retry-After, someone can brute-force logins all day.

4. Debug and stack-trace exposure

Send a deliberately malformed request and read the response body. A stack trace, a file path, or a framework debug page means your errors are handing attackers a map of your backend.

5. Backup existence

This one isn’t a command, it’s a question: does a backup exist, and have you ever actually restored from it? A backup you’ve never restored is a rumor, not a backup. If your platform’s default is a 14-day rolling snapshot you’ve never tested, that’s a warn, not a pass.

6. Authorization and row-level security

Try fetching another user’s record by ID using your app’s own public API key. If it comes back, your database’s row-level security isn’t doing its job, and one user can read another’s data.

7. TLS and HSTS

curl -s -I https://your-app.example.com | grep -i strict-transport-security

No HTTPS at all is a fail. HTTPS with no HSTS header is a warn.

8. Error and PII exposure

Sign up with an email you know is already registered. If the error message echoes that other account’s full email or name back to you, you’re leaking personal data through your own error handling.

9. Dependency CVEs

npm audit --production

Any critical or high-severity finding in a library you actually use in production is a fail.

10. Uptime monitoring

Do you have anything that pages you if the app goes down, or would you hear about it from a user first? No monitoring at all means your users are your monitoring.

11. Admin endpoints

for p in /admin /admin/login /_admin /dashboard/admin; do
  curl -s -o /dev/null -w "%{http_code} $p\n" https://your-app.example.com$p
done

A 200 with real functionality and no login prompt means your admin panel is open to the internet.

12. Client env-var misuse

grep -E "^(VITE_|NEXT_PUBLIC_|REACT_APP_)" .env.example .env 2>/dev/null

Anything with a secret-shaped value behind one of those prefixes is being shipped straight to the browser by design, not by accident, which is worse.

13. Logging and PII retention

Look at a sample of your recent logs. Raw passwords or full payment details, kept forever with no retention policy, is a GDPR problem waiting to surface at the worst time.

14. DNS and mail records

dig TXT yourdomain.com +short | grep spf
dig TXT _dmarc.yourdomain.com +short

No SPF and no DMARC means your domain’s mail can be spoofed, and your password-reset emails might not land at all.

15. Bus factor

If you disappeared for a week, could anyone else deploy a fix, restore a backup, or even get into the servers? “No” is the most common answer we see, and it’s the one check a rescue can’t fix by itself — only an ongoing second person can. Write down, right now, exactly who else has production access and where the credentials live. If the honest answer is “just me, on my laptop,” that’s your real single point of failure, more than any line of code.

Score yourself

Give each check 0 (fail), 1 (warn), or 2 (pass), and add them up out of 30. Below 15 is a real, current risk. 15–23 means the basics mostly hold but real gaps remain. 24 and up is a solid baseline, though check 15 rarely scores a 2 for a solo founder.

Or, we do it for you

If you’d rather have someone else run this list, fix what it finds, and set up backups and monitoring that actually work, get a free 15-point production audit. You get a scored report back in 48 hours, free, yours to keep whatever you decide. If you want it fixed, our rescue services cover exactly these 15 checks at a fixed price.

FAQ

How long does this checklist take to run?

Most of the 15 checks take a few minutes each if you have terminal access to your own app. Checks 5, 10, and 15 are conversations with yourself more than commands.

What if I fail most of these?

That’s normal for an app that grew faster than its ops setup. Fix the frontend-secrets and rate-limiting checks first; they’re both fast and both genuinely dangerous left open.

Is this the same checklist you use for paid audits?

Yes, exactly the same 15 checks, same scoring. The free version is you running it yourself; the paid audit is us running it and writing up the fixes.