What AI-generated SaaS founders should verify before launch

AI made the first version fast. The preview works, the demo lands, the early feedback is good. The question left before opening the doors is more prosaic: what happens when a stranger signs up, pays, makes a mistake, closes the tab and comes back the next day? Here is what I check before a launch, with, for each area, a test you can run yourself.

“It works” is not “it’s ready”

A demo proves the happy path: one account, one test payment, clean data. Production adds what the demo never saw — two users at once, a declined card, a webhook delivered twice, an email that never arrives, a link opened three days later. AI tools often produce code that works on the happy path; what is missing is frequently what does not show on screen: server-side checks, access rules, failure cases. Not always. But often enough to check rather than assume.

Eight areas, one test each

Every area has dozens of possible checks. Here is the one I would run first: it needs no tool, and a “no” changes the launch decision.

Payments: the “thank you” page proves nothing

Access must follow the payment state Stripe confirms to your server through a signed webhook — not the browser landing on the success page, which anyone can open without paying. Stripe can also deliver the same event more than once: processing it the second time must produce the same result as the first. Finally, test a declined card and a refund: access must follow in both directions. Before you switch to live keys, these three tests in test mode are worth more than a code read.

Data: the two-account test

With Supabase, data protection often rests on RLS policies. An exposed table without RLS, or with a policy that is too broad, can let one user read another user’s rows. The test needs no tool: two accounts, two browsers, and the id of one account’s object tried from the other. Run it against the API directly too, not only through the interface: an interface can hide what the API lets through.

Operations: secrets and the way back

A private key placed in a NEXT_PUBLIC_ variable ends up in the JavaScript sent to the browser. Read the list of deployment variables and the Git history. Then ask yourself a concrete question: if the last deploy breaks sign-up at 10 p.m., what do you do? The expected answer fits in two lines — go back to the previous deployment, and know what to do about a database migration that already ran.

Declaring is not verifying

When you tick “yes” on a checklist, you declare. That is useful — it steers — but it is not proof. In my reports, every finding carries one of these four levels:

• Declared: you say so; nobody has checked it.
• Tool-observed: a scan, an automated test or an inspector reported it; to be confirmed in the real context.
• Expert-verified: reproduced, tested or inspected by the person who signs the report, with the evidence described.
• Not checked: in scope but not checked (access, time, environment) — stated as such, never assumed fine.

The distinction prevents the worst position before a launch: believing a point is verified because someone answered yes. The Launch Rescue self-assessment only ever produces declarations, and says so.

What a stop-ship is

A stop-ship is a point to fix — and to verify the fix — before opening to real customers, because its failure directly touches money, another user’s data or the ability to get into the product. Access that does not follow the payment is one; misaligned text on mobile is not. Everything else goes into “before launch”, “after launch” or “optional”, each time with a reason. Sorting like this is what makes a launch possible without waiting for a perfection that does not exist.

What tools can tell you, and what they cannot

A code scan spots patterns: a table without an RLS statement, a public variable that looks like a key, a webhook file without a visible signature check. That is fast and valuable. But a scan reads files. It sees neither the configuration actually deployed, nor the policies active in the database, nor what happens when Stripe replays an event. “Nothing found” means “nothing found in what the tool can read”, not “nothing to find”. Tools speed a review up; they do not replace it.

When to get help

If you can answer yes, with evidence, to the eight tests above, you are already further along than many launches. If not, three options depending on the situation:

• A free first pass, in ten checks: ShipCheck (in French).
• A launch readiness review, with evidenced findings, a prioritised plan and a recommendation about the checked scope: Launch Rescue.
• One precise, confirmed defect to fix: Code Rescue.

For wider remediation beyond a launch, there is AI Product Rescue. Either way, the right question is not “is my app perfect?” — none is — but “what do I actually know, and what am I assuming?”.