The Pre-Launch Checklist for AI-Built Apps: 25 Checks Before You Publish

Building an app with AI has three expensive failure points, and they arrive in a predictable order: you spend more than you meant to, you lose a working version chasing a bug, and you publish something with a key or a database left open. None of them are exotic. They are the same three mistakes almost everyone makes on their first AI-built app, and all three are avoidable with a short list of checks.

What follows is that list, grouped by when it matters. It is deliberately tool-neutral — it applies whether you build with Lovable, Bolt, Replit, v0, Cursor, or VibeSafe Builder. The full version lives in a free, MIT-licensed repo on GitHub you can copy into your own project.

01Before you build: know what a generation costs

Credits hide the thing you actually need to know: what this specific request will cost, and whether it produced anything. Seven checks before your first prompt:

• You know the cost of one generation — either your tool estimates it before you send, or you have done the arithmetic once from its pricing page.
• You have set a hard limit — a cap in the tool, or a spend limit on your API key with the model provider. "I'll keep an eye on it" is not a limit.
• You know whether failed generations cost the same as good ones. On most credit systems they do, which is what makes fix loops so expensive.
• Your first prompt describes one app, not a platform. "A habit tracker with streaks and a weekly chart" builds. "An Airbnb for dog walkers" produces a demo that breaks.
• You started from a template if one fits — regenerating a standard layout from scratch spends money for no gain.
• You know where the app will live — can you download and host it anywhere, or does it only run on the builder's servers?
• You know where the data will live — the visitor's own browser, the platform's database, or yours. This decides what can leak later.

For reference, a single-file app generation on your own Anthropic key runs roughly $0.05–$0.20. The expensive part is never one build. It is thirty builds you did not intend, which is the subject of the next section.

02While you build: progress, not loops

The classic credit-burner is the fix loop — the AI fixes A, breaks B, then fixes B and reintroduces A. It happens because the model re-reads the code fresh each turn with no memory of why earlier choices were made, and because its own failed attempt sits in the conversation as a pattern to repeat. We wrote about the mechanism in detail in the AI doom loop.

• Save a working version before every significant change. If your tool has version history, confirm it is on. If not, download a copy.
• Change one thing per prompt. Three requests in one message make it impossible to tell which broke what.
• Stop after two failed fixes on the same problem. Roll back and change approach instead of asking a third time.
• Roll back rather than re-prompt when a change makes things worse. Rolling back is free; asking the AI to undo its own change is another paid generation that often does not fully undo.
• Read what changed, not just whether it runs. Unexpected edits to parts you never mentioned are an early warning.
• Test at phone size. Most first versions are desktop-only by accident.
• Check your spend at the halfway point and rethink scope if you are past half the budget and less than half done.

This is the reasoning behind two specific behaviours in VibeSafe Builder: failed generations are tracked separately and never counted against your build spend, and after two failed fix attempts on the same issue the next generation switches to re-diagnosing the root cause instead of retrying the same fix.

03Before you publish: the checks that prevent incidents

This is the group people skip, and it is the group that produces the headlines. In January 2026 an AI-built social network shipped a database key in client-side JavaScript with no row-level security, and researchers pulled 1.5 million auth tokens out of it within three days. The full story is in why AI-built apps leak databases. Eleven checks:

• No secret keys in the code. Search for sk-, sk_live_, AKIA, service_role, and long eyJ… tokens. Anything running in the browser is readable by every visitor.
• Publishable and secret keys are the right way round. A Stripe pk_ and a Supabase anon key are designed to be public. A Stripe sk_ and a Supabase service-role key must never be.
• Database access is restricted — Row Level Security on every Supabase table; Firebase rules that are not allow read, write: if true.
• You have asked "if someone found this URL, what could they see?" and then actually checked, logged out, in a private window.
• The app only talks to services you chose. Unexpected outbound requests are invisible in a normal demo.
• No eval() or code built from user input.
• No passwords in browser storage. localStorage is readable by any script on the page.
• HTTPS with no certificate warnings, on both the plain domain and the www version.
• You have run it as a visitor would, not only in the builder's preview. Previews hide errors that appear once published.
• You have a copy you control — a downloaded file or a repo you have actually tested running elsewhere.
• You know what happens if the builder disappears or you stop paying. Write the answer down. The four separate kinds of lock-in are covered in this post.

In VibeSafe Builder these run automatically: every generation is scanned server-side for hardcoded keys, eval(), and unexpected outbound requests, publishing is blocked outright on a critical finding, and Launch Check opens the finished app in a real browser to catch what a code scan alone would miss. Neither replaces a professional security review for anything handling real user data at scale — they catch the specific class of mistake that took that social network down.

04If you only do five things

1. Know the cost before you hit send, or set a hard budget yourself.
2. Save a working version before every big change.
3. Stop after two failed fixes and change approach.
4. Search your code for keys before publishing.
5. Ask what a stranger with the URL could see — then check.

Those five prevent most of the money and most of the incidents. The remaining twenty are refinements.

05Take the checklist with you

The complete 25-check list, a cost guide, and copy-paste prompts for the common failures — a fix loop, a leaked key, an open database, an app you cannot get out of the builder — are in the AI App Builder Checklist repo. It is MIT licensed, so copy it into your own docs freely.

If you would rather the checks ran on their own, that is what VibeSafe Builder is: an AI app builder that shows the cost before every build, keeps every version reversible, and scans each build before you publish. You can try the demo without an account, or see the pricing — there is no platform fee on your own API key.

06Related reading

Where your AI credits actually go
The AI doom loop, and what breaks it
Why your AI-built app might already be exposing its database
AI app builder lock-in: the four kinds