Seven ways a launch goes wrong, in founders' own words

If you're about to put real users or real money on an app, these are the seven fears I keep seeing in founders' public posts before a launch. For each one I've put the founder's own words, what it has cost people where a reliable source says so, and a check you can run yourself today.

Published October 21, 2026

1 "A date is coming and I can't tell if it's safe to launch"

What it has cost

The risk is launching with a problem nobody has looked for. Escape, a security company, ran a passive scan of more than 5,600 publicly available apps built with AI coding tools and found more than 2,000 vulnerabilities, more than 400 exposed secrets and 175 exposures of personal data, including medical records reported (Escape). "Vulnerabilities" is their word, and they don't say how many were serious.

In February 2026, Wiz, a cloud security company, found that Moltbook, an AI social network that had just gone viral, left its production database open to anyone, read and write, with 1.5 million login tokens in it (keys that let anyone take over any agent's account on the site). Wiz quotes the founder saying he didn't write a single line of its code reported (Wiz).

Check it yourself

1. Before the date, run the ten-minute checks at the top of my security self-check.
2. Write down what "safe enough" means for this launch, in plain words: no table a stranger can read, no secret key in the code, every payment recorded by the server. Then check each line separately.

2 "Strangers can read or change my users' data"

What it has cost

Matt Palmer, who reported the flaw as CVE-2025-48757 (he works in developer relations at Replit, which also makes an AI app builder), checked 1,645 projects listed on Lovable's showcase in March 2025 and found 303 weak spots across 170 of them (about 10.3%) where the database's access rules didn't protect user data, which included names, phone numbers, payment details and API keys reported (Palmer). Those rules are row-level security (RLS): the database setting that decides who can read or change each row.

The problem was still common in September 2026, when UpGuard, a security company, published a scan of about 300,000 domains that use Supabase. It found 16,326 databases with tables anyone visiting the site could read reported (UpGuard).

In July 2025, Tea, a dating-safety app, said about 72,000 images were taken from a legacy storage system, about 13,000 of them selfies and photo IDs users had sent to verify their accounts. Reporters, citing an anonymous 4chan post and the news site 404 Media, said the files sat in an unsecured Firebase storage bucket (an online folder for files) reported (Security Affairs).

Check it yourself

1. Open your app in a private browser window, signed out, and run check 1 of the self-check: can a stranger read or change your tables?
2. Then sign in as one test user and try to load another test user's data, for example by changing the ID number in the page's web address to the other user's. If that works, any signed-in user can read other users' data. Check 4 covers admin actions the same way.
3. Check your file storage too. If anyone can open the folder where users' files are stored, it's the same leak as an open table.

3 "A payment goes through but my app never records it"

When Stripe takes a payment, it sends your app a message called a webhook to say so. If that message fails, your app never hears about the payment.

What it has cost

If your app doesn't answer that it got a webhook, Stripe retries for up to three days in live mode, and its list of past events only goes back 30 days measured (Stripe's documentation). So a webhook that quietly fails for more than three days stops being retried, and you have to find and fix the paid orders it missed by hand derived. Stripe's advice is to reply quickly and do the work afterwards, so the safe pattern is to save the event first and process it next. It also says to check Stripe's signature on every event, because without that check anyone can send your app a fake one measured (Stripe's documentation). Stripe also counts any redirect as a failure, so a webhook address that forwards somewhere else fails every time measured (Stripe Support).

Check it yourself

1. In your Stripe dashboard, open your webhook endpoint and look for failed deliveries. Any failure in the last month is a payment your app may not know about.
2. Make a test payment in test mode, then check that your database changed, not only that the page said "thanks".
3. Ask the tool that built your payment code: "Does my webhook check Stripe's signature on every event, save each event before it replies, then process it, skipping any event it has already seen? And can anything in the browser mark an order paid?" If it can't show you the lines, treat the answer as no (check 5).

4 "Someone runs up a bill on my account"

An API key is the password your app uses to call a paid service such as Gemini, Google's AI service. Anyone who has it can run up charges on your account.

What it has cost

That tire shop's bill came from an old, unrestricted Google Maps key that gained access to Gemini, Google's AI service, once Gemini was switched on for the account reported (the poster's account). Truffle Security, a company that builds secret-scanning tools, found 2,863 live Google API keys, the kind developers used to treat as safe to publish, that could reach Gemini reported (Truffle Security). In March 2026, Tom's Hardware reported a Reddit post by one of three developers at a small firm: a Gemini key they suspect was stolen took their usual spend of about $180 a month to more than $82,000 in 48 hours. They said Google's support pointed to its shared-responsibility model (that keeping the key safe was the customer's job) reported (Tom's Hardware).

Deleting a leaked key from your code doesn't make it safe. GitGuardian, a company that scans for leaked secrets, found that of the working secrets it detected on public GitHub in 2022, 64% still worked four years later reported (GitGuardian).

Check it yourself

1. Run check 7 (can a stranger use your AI account?), check 8 (a secret key in the code your visitors' browsers download) and check 9 (a secret anywhere in your git history).
2. Restrict every API key to the services and sites that need it (in Google Cloud: APIs & Services, then Credentials, then edit the key), and replace any key that was ever public.
3. Set a budget alert with each paid service. A budget alert only emails you, it can arrive hours late, and it won't stop the charges. Where a service offers a spending cap, set one too measured (Google Cloud's documentation).

5 "My data could vanish and I have no copy"

What it has cost

In July 2025, Replit's AI coding agent deleted live records for 1,206 executives and more than 1,196 companies from SaaStr's database during a code freeze, by the agent's own account. SaaStr's founder, Jason Lemkin, later wrote that Replit's rollback (its option to restore an earlier saved copy) did work, though the agent had first said it wouldn't reported (Tom's Hardware, The Register). In April 2026, an AI coding agent deleted the live database of PocketOS, a software company, and its backups with it, because the backups were kept on the same disk as the data. The hosting company's CEO helped restore the data within an hour reported (TechRadar).

Supabase backs up Pro, Team and Enterprise projects automatically every day, with 7 days kept on Pro. For free projects, it recommends exporting your own data with its command-line tool measured (Supabase's documentation).

Check it yourself

1. Find out which plan you're on and when your last backup ran. On a free plan, the answer may be never.
2. Make your own copy and save it outside the project. On Supabase, a plain supabase db dump copies the structure but not your data measured (Supabase's command reference). Ask your AI coding tool to follow Supabase's backup and restore guide, which makes separate dumps of the structure, the data and the roles. That copy doesn't include uploaded files, so back those up separately measured (Supabase's guide).
3. Restore the copy once into a spare project and check that your rows came back. Until you've restored the copy once, you don't know it works.
4. Don't give an AI agent write access to your live database. Let it work on a copy.

6 "It broke in production and support isn't answering"

What it has cost

For that clinic, more than 12 hours of a live system down in its busiest stretch, by the team's own report reported (the team's post). Only the platform's staff can fix many problems like this one, and while you wait, changes you try yourself can make it worse derived. Supabase, for example, offers guaranteed support response times only to Team and Enterprise customers measured (Supabase's support policy).

Check it yourself

1. Before launch, read what support your plan actually includes and how fast it promises to answer.
2. Keep a short written note of each change you make to the live system and how to undo it, so you can step back without guessing.
3. Avoid big changes, such as resizing the database or changing its structure (a migration), in the days around a launch or a campaign.

7 "I can't judge what the AI wrote"

What it has cost

The closest figure I trust: Veracode, an application security company, gave more than 100 AI models 80 coding tasks, and they chose the insecure way to write the code 45% of the time reported (Veracode). I haven't found a reliable dollar figure for this fear on its own. When it does cost money, it's usually through one of the six problems above.

Check it yourself

1. Pick the three riskiest parts of your app: sign-in, payments, and anything that reads one user's data for another.
2. For each, ask the tool that wrote it to explain, line by line, what stops a stranger from using it. If the answer is that the page hides the button, nothing stops a stranger, because anyone can send the request to your server without using the page.
3. Have someone who didn't write it read those three parts before launch.

How I got this

From September 26 to October 10, 2026, I read founders' public posts about launching apps, many of them built with AI tools, on GitHub, vendor forums, Reddit and job boards, and grouped what they were afraid of. These seven came up most in what I read. That's my reading of public posts, not a survey, and it leans toward people building on Supabase and similar services, because that's where I read most.

The quotes come only from posts I could open and link again on October 21 (on Hacker News, GitHub and vendor forums), so some are older or newer than my reading window. "Founders" here means the people building and launching the apps, whatever they call themselves. I leave out every poster's name, and I don't quote anyone who asked me for help. The costs come from security companies' and researchers' own reports, established tech news outlets, the platforms' own documentation and, where I say so, the posters' own accounts. I rechecked every figure against its source on October 21, 2026. The labels say how far each one goes:

Measured

I counted it myself, or read it on the source that owns the fact (a product's own documentation, say).

Reported

A named source says it, and I can't check it myself.

Derived

My own reasoning or arithmetic from the two above.

Sources

1. Hacker News, "Ask HN: What's on your SaaS launch checklist?", March 20, 2025. news.ycombinator.com
2. Hacker News, "Ask HN: How would you harden AI changes to a 1M-line legacy SaaS before review?", July 25, 2026. news.ycombinator.com
3. Escape, its method write-up for a passive scan of apps built with AI coding tools, October 29, 2025. escape.tech
4. Wiz, "Hacking Moltbook: The AI Social Network Any Human Can Control", February 2, 2026. www.wiz.io
5. Hacker News, a developer's post about a secret database key found in their own side project, August 11, 2026. news.ycombinator.com
6. Matt Palmer, statement on CVE-2025-48757 (exposed data in apps built with Lovable), May 29, 2025. mattpalmer.io
7. UpGuard, "Everything Everywhere: Systemic Data Exposure in Supabase Apps", September 24, 2026, updated October 14, 2026. www.upguard.com
8. Security Affairs, report on the Tea app breach, quoting Tea's own notice, July 29, 2025. securityaffairs.com
9. Vercel Community, "Stripe Webhook 405 Error", November 17, 2025. community.vercel.com
10. GitHub, Supabase discussion 52010, "Two silent failures that cost me days on Supabase (webhook JWT, RPC type mismatch)", October 20, 2026. github.com
11. Stripe documentation, "Webhooks" and "Manage webhook endpoints" (undated; read October 21, 2026). docs.stripe.com
12. Stripe Support, "Webhooks: what to do when the HTTP status code starts with a three (3xx)" (undated; read October 21, 2026). support.stripe.com
13. Google AI Developers Forum, a tire shop owner's thread about an unrestricted API key and a Gemini bill of about $14,000, June 12, 2026. discuss.ai.google.dev
14. Google AI Developers Forum, a developer's refund request for about $2,200 in Gemini charges from a leaked client-side key, April 21, 2026. discuss.ai.google.dev
15. Truffle Security, "Google API Keys Weren't Secrets. But then Gemini Changed the Rules.", February 25, 2026. trufflesecurity.com
16. Tom's Hardware, report on an $82,314 bill from a stolen Gemini API key, March 4, 2026. www.tomshardware.com
17. GitGuardian, "The State of Secrets Sprawl 2026" (fifth edition, 2026). www.gitguardian.com
18. GitHub, Supabase discussion 47615, "production DB empty, backups empty... WTF", July 5, 2026. github.com
19. GitHub, Supabase discussion 43997, "Lost entire database after running migration down --last 1 command", March 19, 2026. github.com
20. Tom's Hardware, report on Replit's AI agent deleting SaaStr's production database, July 21, 2025. www.tomshardware.com
21. The Register, report on Replit deleting SaaStr's production database, July 21, 2025, quoting Jason Lemkin's posts, as archived by the AI Incident Database (report 5578). incidentdatabase.ai
22. TechRadar, report on an AI coding agent wiping PocketOS's database and backups, May 2, 2026. www.techradar.com
23. Supabase documentation, CLI reference for "supabase db dump" (undated; read October 21, 2026). supabase.com
24. Supabase documentation, "Backup and Restore using the CLI" (undated; read October 21, 2026). supabase.com
25. Supabase documentation, "Database Backups" (undated; read October 21, 2026). supabase.com
26. GitHub, Supabase discussion 51135, a medical clinic's production database down more than 12 hours, through a resize meant to recover it, October 1, 2026. github.com
27. GitHub, Supabase discussion 50787, a free-plan production database down more than 24 hours with a full disk, September 23, 2026. github.com
28. Supabase, "Support Policy" (undated; read October 21, 2026). supabase.com
29. Google Cloud documentation, "Create, edit, or delete budgets and budget alerts" (undated; read October 21, 2026). docs.cloud.google.com
30. Veracode, press release on its research into the security of AI-generated code, July 30, 2025. www.veracode.com

Want me to look at your app?

Or check it yourself first: the security self-check walks through eleven checks you can run from your database's dashboard and your code repository (its examples use Supabase and GitHub).