Part of the vibe-coded app security audit.
What to check before you launch an app you didn't write
Last updated 18 September 2026 · verified against each platform’s own documentation
Is my AI-built app ready to launch? The short version
There are four major questions to be answered before you'll know if your app will survive. An AI app builder answers just one of the four questions: “can this be built” . Worse, it only answers half of that one. AI will prove something runs, not prove you can keep it running safely once other people depend on it.
In a June 2026 audit of 200 deployed vibe-coded applications, 90% had at least one vulnerability, 76.7% of those were rated Critical or High, and broken access control showed up in three-quarters of the codebases examined, meaning one user can access data for another user.
Below are 31 checks worth looking at. They will help you answer the four questions that your app needs to stand up to.
The one question your builder already answered
Writing code has never been the hard work. It was only the most expensive.
AI-code platforms have driven that expense down to basically free, which has unleashed a flurry of creativity and entrepreneurship and also a great deal of confusion about what has actually been solved. A product has four ways to die: people don't want it (no value), they can't figure out how to use it (usability), you can't actually build it (technical feasibility), it doesn't work as a business (cost more to support than than you'll make up in revenue). Marty Cagan laid these out in The Four Big Risks, 2017. His advice was to tackle the value and business risks first, because those are the ones that kill you quietly.
A vibe-coded prototype answers the third one and hands you a running application, which feels like a much bigger victory than it is. Cagan's version of that risk is whether your engineers can build the thing with the time, skills and technology you have. The build became cheap while running and productionalizing the app did not.
The security failures everyone worries about are not a fifth risk. They're the usability and viability risks stacked on top of one another in a trenchcoat. An app that shows one customer another customer's records is not usable by anyone. An app with your Stripe key sitting in the browser bundle is not a viable business
I could philosophize on how product management and the art of derisking your build are more important than ever in the age of AI, but you came here for a checklist so here it is.
Risk 1: Does anyone want it? (4 checks)
If these four fail, the other twenty-seven are a very thorough inspection of a house nobody is going to buy. For a deeper dive on these questions, see A PM Primer for No-Code Developers.
Five people outside your network have used it for real work. No platform runs this for you.
Not clicked through a demo. Used it for something they actually needed done.
At least one of them asked when they could keep using it. No platform runs this for you.
Unprompted. Your friends will be polite, but if they really found value, they’ll ask to keep using it.
You can name the one job someone opens this app to do. No platform runs this for you.
In a sentence, without listing features.
You know what those people do today instead, and why this is better. No platform runs this for you.
Usually the answer is a spreadsheet. Sometimes it’s nothing.
Risk 2: Can someone other than you use it? (5 checks)
Someone completed the main workflow without you in the room.
This is classic UX work. Can the user complete the workflow without you hand-holding?
You watched them do it and wrote down where they hesitated. No platform runs this for you.
Hesitation is a signal that they may not call out but that points to something being confusing to them.
A brand-new account can get from signup to first value unassisted.
Fresh browser profile, fresh email address, no autofilled anything. Your logged-in session has been lying to you for weeks.
Every dead end shows a message, not a blank screen.
Go break things on purpose. Submit the empty form, upload the wrong file type, hit the back button mid-flow. There are great QA writeups that can help you break your app.
It works on a phone, if any part of the job happens on one.
Most software gets used on a phone. Unless you have a good reason to think your app won't be, make sure to check.
Risk 3: Access and data: who can see what (8 checks)
This is the center of gravity. Broken access control is the single largest category in the arXiv study at about 36% of all vulnerabilities found, present in 75.5% of repositories. OWASP has it ranked #1 across all software, not just the AI-built kind.
Row-level security, or whatever your stack relies on, is on for every table and has a policy.
Enabled with no policy is a locked door with no walls. On Lovable or Bolt this is a Supabase policy — here's how row-level security fails in a Lovable app. On Replit, there is no database backstop underneath your routes at all. On Base44 it's an entity access rule, enforced by their backend.
A second test account cannot see the first account’s records. No platform runs this for you.
You tested this by logging in as both. Two browsers, two accounts, ten minutes.
Changing an ID in a URL returns a permission error, not somebody else’s data.
This is known as Insecure Direct Object References (IDOR), and it is the most embarrassing way to find out you have a problem, because your customer finds it by typo.
Every write endpoint checks who is calling before it writes.
Symbiotic’s scan of 1,072 Supabase-backed apps found 172 sites that allowed unauthenticated record deletion.
Every read endpoint filters by the caller’s identity, not by an ID the caller handed you.
Every user can use off-the-shelf tools to see what kind of endpoints your application calls during normal operation. If your application doesn't double check their identity, there's nothing to stop a bad actor from spamming those endpoints with different identifiers to try and pull out protected information.
Login blocks the route on the server, not just the button in the interface. No platform runs this for you.
OWASP puts it flatly: access control "is only effective in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata."
Users cannot edit their own role or permission fields.
Look at what a user is allowed to change on their own record. If is_admin is in that list, you’ve built a promotion button.
Admin routes have a server-side role check, tested by hitting them directly while signed in as a normal user.
Risk 3 1/2: Keys and secrets (4 checks)
Cryptographic failures were 20.7% of everything the arXiv team found, in 63% of repositories — including OAuth tokens sitting base64-encoded in frontend storage, which is not encryption, it is a hat.
View source, search the bundle for your keys.
Anything prefixed VITE_ or NEXT_PUBLIC_ is in the browser by design. Know which of yours are, and make sure none of that information controls any access to anything, so it can't be misused.
No secret has ever been committed to git — including history.
AxonBuild’s 2026 audit corpus found six apps with real exposed secrets, and three of those were in git history rather than the working tree. Deleting the line does not delete the line.
Every third-party key is scoped to the minimum it needs, and you know what each one can spend.
An OpenAI key with no limit attached to a credit card is a very fast way to fund a stranger’s hobby.
You can rotate every key without the app going down, and you know how.
Risk 4: Money and Business (5 checks)
A real payment, in production mode, reached your bank.
A test-mode success screen proves Stripe’s test mode works. It has always worked.
Payment webhooks verify their signature before granting anything.
Otherwise anyone who learns your webhook URL can grant themselves a subscription by sending you a nicely formatted lie.
What a customer gets is derived from what they paid, in one place, checked server-side.
A failed payment tells the customer what happened and does not silently grant access.
Every metered API call has a spend ceiling. No platform runs this for you.
AI features, email, SMS, storage. Twelve of the fourteen AI-featured apps in AxonBuild’s corpus had no ceiling on any of them. This is the failure mode that turns a quiet Tuesday into a four-figure invoice.
Bonus Risk 5: What happens when it breaks (5 checks)
Errors reach you, not just the user.
If you find out from a customer, this check fails. If you find out from a customer’s tweet, it fails harder.
Auth and write endpoints have rate limits.
Missing rate limits were the most common flaw class in the Xint testing SecurityWeek covered with 93 findings, more than any other category.
SecurityWeek — Vibe-coded apps riddled with exploitable flaws
Error messages tell the user what to do and tell you what happened.
The user’s contains no stack trace, and no blank screen quietly burning tokens while it waits for something that is never coming.
You have restored a backup. No platform runs this for you.
Not "have backups." Restored one, to a working state, with a stopwatch running. Everyone has backups. Almost nobody has a restore.
You can get your code and your data out today without asking anyone’s permission.
Replit: git. Lovable and Bolt: GitHub sync. Base44: eject gives you code and schemas, but not your data rows, your users, or the permission enforcement.
The nine checks no platform runs for you
Checks 1, 2, 3, 4, 6, 11, 15, 26 and 30.
It would be easy, and wrong, to say the platforms skip this but that's not technically true (the best type of true). They publish thorough checklists that stop exactly where their responsibility does. Supabase's production checklist says plainly: “Ensure you have enabled row level security (RLS) on all tables,” because “tables that do not have RLS enabled with reasonable policies allow any client to access and modify their data.”
Their checklists are complete for their job but they'll stop short of yours.
If it's a customer asking rather than you, here's what to send when someone requests your SOC 2.
If everything above passes, you don't need us
Sad to say, but it happens. If you got through 31 checks and they held, congrats! You have done the work, and the honest thing for me to say is: ship it or zip it. Most prototypes should not be paying anyone.
What we sell is the version of this list that someone else runs, with the code open in front of them — $499, 1 week. The reason to hire it out is usually that you don't have a person who can read every policy line by line, or that you have one and they're the person who wrote it.
When you promote your prototype to the big stage, the point is to stop prompting and praying. People have been launching software for decades. The cost to build it has been flattened. The list has not.
Before you launch
- Can the right people access the right parts of the app—and nobody else?
- Is customer information kept private and separated correctly?
- Are passwords, payment keys, and other sensitive information protected?
- Could someone reach data or features they shouldn’t be able to?
- What could break, expose customer information, or become costly as you grow?
You get a severity-ordered report, covering vulnerabilities as well as best-practices to help you speed up delivery, with a remediation roadmap to help you address any issues. Plus a breakdown of your architecture to help you understand your application.
$499 fixed price · 1 week
Book an AuditCommon questions
- What do I need to check before launching my app?
- The 31 checks above, in six groups: whether anyone wants it, whether anyone else can use it, who can see what data, where your keys are, whether the money works, and what happens when it breaks. If you only have an afternoon, do checks 11, 15, 18 and 30. Those four catch the failures we see most often.
- Is my AI-built app secure enough to launch?
- The base rate says probably not yet. A June 2026 audit of 200 deployed vibe-coded apps found 90% had at least one vulnerability and three-quarters had a broken access control flaw. That’s a population number, not a verdict on your app — which is what checks 10 through 17 are for.
- Does my platform already check this for me?
- Partly. Most platforms now run some kind of automatic scan, and several publish good production checklists. They cover the platform’s half. Nine of the 31 checks here are things no platform will do for you, and they’re marked.
- How long does this list take?
- Parts 3 through 6 are an afternoon if you’re comfortable in your own codebase. Parts 1 and 2 take a couple of weeks, because they require other humans and other humans have schedules.
- What if I fail a check and don't know how to fix it?
- Most of them have a documented fix and an AI coder can do the work, provided you tell it exactly what’s wrong. The ones that don’t go that way are usually authorization logic, where the code is doing precisely what it was told and what it was told is backwards.
The copyable version
AI APP PRODUCTION CHECKLIST — 31 CHECKS BEFORE LAUNCH
[MANUAL VERIFICATION ONLY] = no platform runs this for you
Free, no email needed. Same 31 checks as this page.
DOES ANYONE WANT IT?
- 1. Five people outside your network used it for real work [MANUAL VERIFICATION ONLY]
- 2. One of them asked, unprompted, to keep using it [MANUAL VERIFICATION ONLY]
- 3. You can name the one job the app is opened to do [MANUAL VERIFICATION ONLY]
- 4. You know what they do today instead, and why this is better [MANUAL VERIFICATION ONLY]
CAN SOMEONE OTHER THAN YOU USE IT?
- 5. Someone completed the main workflow without you in the room
- 6. You watched and wrote down where they hesitated [MANUAL VERIFICATION ONLY]
- 7. A brand-new account reaches first value unassisted
- 8. Every dead end shows a message, not a blank screen
- 9. It works on a phone, if the job happens on one
ACCESS AND DATA
- 10. Row-level security on for every table, with a policy
- 11. A second account cannot see the first account’s records [MANUAL VERIFICATION ONLY]
- 12. Changing an ID in a URL returns a permission error
- 13. Every write endpoint checks who is calling
- 14. Every read endpoint filters by caller identity
- 15. Login blocks the route on the server, not just the button [MANUAL VERIFICATION ONLY]
- 16. Users cannot edit their own role or permission fields
- 17. Admin routes have a server-side role check, tested directly
KEYS AND SECRETS
- 18. You searched the browser bundle for your keys
- 19. No secret in git, including history
- 20. Every third-party key scoped, and you know what it can spend
- 21. You can rotate every key without downtime
MONEY
- 22. A real payment, production mode, reached your bank
- 23. Payment webhooks verify their signature
- 24. Entitlement derives from payment, server-side, in one place
- 25. Failed payments explain themselves and grant nothing
- 26. Every metered API call has a spend ceiling [MANUAL VERIFICATION ONLY]
WHEN IT BREAKS
- 27. Errors reach you, not just the user
- 28. Auth and write endpoints have rate limits
- 29. User-facing and internal error messages differ
- 30. You have restored a backup, not just taken one [MANUAL VERIFICATION ONLY]
- 31. You can export your code and data today, unassisted
Checklist by Aspen Automation
aspen-automation.com/ai-app-production-checklist