Launching a Lovable, Bolt or Cursor app: the checklist

Your app works and you want to open it to real users. Before you share the link, take the time to run through this checklist: most launch surprises come from points that could have been checked the day before.

Why a checklist

A pilot knows the aircraft inside out and still runs the list before every takeoff. Not from lack of confidence: under pressure, people forget. A launch is that same moment. Everything seems ready, the urge to move is strong, and that is when a step gets skipped.

An app shown to a few friends forgives a lot. An app opened to the public forgives little: personal data moves around, money may change hands, and an incident damages trust.

The checklist

Data and security

1. Database access rules are in place. Each user sees only their own data. Test with two accounts. See database access rules.
2. No secret key is visible in the code sent to the browser. See exposed API keys.
3. Admin pages require sign-in and a role. Try their address while signed out.
4. Passwords are stored safely, never in plain text (see hashing).

Reliability

5. A backup exists, and you know how to restore it. A backup you never tested is a hypothesis, not a safeguard.
6. You have a test environment separate from production. Changes are tried on a copy, never directly in front of users. See staging vs production.
7. You can roll back. If an update breaks something, you get the previous version back in minutes rather than hours of panic.
8. You will be told about an error. Without error monitoring, the app can stop working for some users and you will learn about it from their messages.

The framework around it

9. The site uses HTTPS (the padlock in the browser), on your own domain name, with outgoing emails that do not land in spam.
10. Legal obligations are covered: legal notices, privacy policy, consent where required. Have this validated if you handle personal data from individuals.

A test nobody runs

Before launch, walk the whole path as a stranger: create an account with a fresh address, perform your product's main action, sign out, sign back in, request a forgotten password. This walk-through often reveals more than reading the code. To make it repeatable, that is the job of automated tests.

When there is no time to check everything

Prioritise three things: who sees what, where the keys are, how to restore. They carry the heaviest consequences and are the hardest to recover from. The rest can be fixed after launch, within days, without drama.

Remember

Before opening to the public, check data access, keys, backups and the ability to roll back. Checking before launch costs less than repairing afterwards.

And for your product?

If you would rather have an outside person run this list for you, our audit is made for that: it starts from your app as it is and hands back what to fix before launch, in order of importance. Let us talk it over in a 30-minute call.