DEV Community

Milo Antaeus
Milo Antaeus

Posted on • Originally published at miloantaeus.com

The 6 things every vibe-coded app needs to pass before you launch it in 2026

#ai #security #startup #devops

The 6 things every vibe-coded app needs to pass before you launch it in 2026

45% of AI-generated code ships with a security flaw. 20% of vibe-coded apps in production have a serious vulnerability. The gap is checkable in 30 minutes.

A founder I worked with last month had a Replit app that had been live for nine days. The landing page took emails, the dashboard accepted file uploads, the Stripe checkout was wired to a single product, and the founder had no idea what the AI assistant had shipped under the hood.

The Wiz study (May 2026) found 20% of vibe-coded apps in production have serious vulnerabilities. Master of Code (also May 2026) found 45% ship with at least one security flaw. Martin Fowler's "VibeSec Reckoning" (May 27, 2026) called it systemic exposure. The Cloud Security Alliance linked the surge to the AI-Generated CVE wave of early 2026.

The good news: most of the launch-blocking problems are checkable in 30 minutes by a non-technical founder with a checklist. You do not need a penetration test, a security certification, or a compliance audit to know whether your app is safe enough to take its first 100 users. You need a pre-launch safety triage that any founder can run, six sections, yes/no per question, score-yourself bands at the end.

This article is that checklist. No frameworks, no vendor pitch, no exploit walkthroughs. If you want the human forensic read at the end of it, the link is at the bottom.

Why "vibe-coded" is its own risk shape

Vibe-coded apps are not legacy codebases with AI suggestions sprinkled on top. They are usually:

  • A single prompt history that the founder no longer fully understands.
  • Two to five framework files that may or may not match what was deployed.
  • Environment variables that were "just for testing" and are now in the production build.
  • An auth flow that "seemed to work" but might not have session expiry, password hashing, or rate limiting.
  • An upload handler that may or may not validate file types at the boundary.
  • A payment flow that may or may not have a refund path and may or may not reconcile with the processor.

The reason security teams are worried in 2026 is not that any one of these is exotic. It is that all six are common, silent, and ship in the same app at the same time, because a non-technical founder is moving fast and there is no human reviewer in the loop. The Wiz number (20% serious) is conservative when you include the apps that work but leak data quietly.

The 6 sections below are the ones that catch the highest-blast-radius problems before launch. They are not the only sections. They are the ones that, if missed, will hurt you before anything else does.

Section 1: Intake forms

What you are collecting: email addresses, account credentials, file uploads, support messages, or — in some apps — payment information that you then type into a processor manually.

The 4 checks:

  1. Is every form a known shape? Open your live app, submit a normal entry, and confirm the data lands somewhere you control (a database, a spreadsheet, a CRM, a Notion page, an email). If a form submits and you do not know where the data goes, that is a launch blocker.
  2. Are sensitive inputs validated server-side? Type ' into a name field. If the form crashes or returns 500, the validation is only on the client. Client-only validation is a XSS surface. Server-side validation is required.
  3. Do upload fields restrict file type AND size? If a user can upload a 500 MB PHP file with the name .pdf, you have a code-execution surface. Whitelist by extension AND content-type, and cap at a sane size.
  4. Do you have a delete / redact path for submitted data? If a user emails you "delete my data", can you do it in under 24 hours? If not, that is a launch blocker for any app collecting real user data in any jurisdiction with a privacy law (California, EU, Brazil, etc.).

Score yourself: 4/4 = ready. 3/4 = probably ready, fix the gap before paid traffic. 2/4 or below = launch-blocked.

Section 2: Privacy copy and policy surface

The terms of service, privacy policy, and any "we use your data for X" copy on the live site is what a regulator, a customer, or a journalist will look at first. Vibe-coded apps frequently ship with the AI's default placeholder privacy policy, which is usually wrong for the actual product.

The 3 checks:

  1. Is the privacy policy specific to what the app actually does? Read the policy and the app side by side. If the policy mentions "we collect usage data to improve our service" but the app collects payment info, location, or biometrics, the policy is a misrepresentation.
  2. Is the data retention statement honest? "We retain your data for as long as your account is active" is a real commitment. "We may retain your data for up to 7 years for tax and audit purposes" is a different commitment. Pick the one that is true.
  3. Is there a contact path for privacy requests? A working email address (not a form-to-nowhere) and a stated response window (48 hours is the GDPR norm). If a user cannot find it, the policy is not a policy, it is decoration.

Score yourself: 3/3 = ready. 2/3 = fix the gap before any traffic that could plausibly be in a regulated jurisdiction. 1/3 or below = launch-blocked.

Section 3: Checkout and payment evidence

The payment flow is the highest-blast-radius surface in any vibe-coded app because it touches money, identity, and trust at the same time.

The 4 checks:

  1. Is the processor you wired actually the one you think it is? Open the production URL. Click checkout. Read the URL bar at the redirect destination. If it is checkout.stripe.com or www.paypal.com/cgi-bin/webscr, you are on a real processor. If it is your own domain or a domain you do not recognize, the form is fake and the money is not going where you think.
  2. Can you prove a payment happened from the processor side, not the app side? The processor dashboard (Stripe, PayPal, Gumroad, etc.) is the source of truth. The app's database is not. If the app says "payment complete" but the processor dashboard has no matching transaction, the app is lying.
  3. Is there a refund path? If a customer emails "I want a refund", can you do it without code changes, in the processor dashboard, in under 5 minutes? If not, write the refund flow before you take paid traffic.
  4. Is the test mode separated from live mode? If your dashboard shows test transactions from before launch, your test webhook is still wired to live, or both. That is a real-money risk.

Score yourself: 4/4 = ready. 3/4 = probably ready, document the gap. 2/4 or below = launch-blocked for any paid product.

Section 4: Upload boundaries

Upload fields are a top-3 source of incidents in vibe-coded apps because the AI assistant will frequently implement them with a permissive default (accept any file, no size cap, no type check).

The 3 checks:

  1. Is there a hard size cap? Try uploading a 1 GB file. If the request succeeds, there is no cap, and you have a denial-of-service surface.
  2. Is the file type checked by content, not just by extension? A file named avatar.jpg may actually be a PHP script. Check the magic bytes server-side. If you cannot write the check, restrict to image types and use a library that does it for you.
  3. Is the upload directory outside the web root? If a malicious file gets uploaded into a directory that is served as static, it can be requested by URL and executed. Store uploads in a directory the web server does not serve directly, and serve them through a controller that enforces the right content-type.

Score yourself: 3/3 = ready. 2/3 = fix before any user-generated content (UGC) feature is exposed. 1/3 or below = launch-blocked for any app with an upload field.

Section 5: Auth and account promises

Most vibe-coded apps have some form of auth — sign-up, login, password reset, sometimes OAuth. The risk is in the things the AI did not implement, not the things it did.

The 4 checks:

  1. Are passwords hashed, not stored plain? Open your database (or the auth provider's dashboard). If you can read the password column and see "hunter2", the passwords are stored plain. That is a launch blocker.
  2. Is there a session expiry? Sign in, walk away for 24 hours, come back. Are you still signed in? If yes, sessions do not expire. That is a risk.
  3. Is there a rate limit on login attempts? Try 100 failed logins in a minute. If the 101st still says "wrong password" instead of "too many attempts", you have a brute-force surface.
  4. Is the password reset flow token-based and time-limited? If the reset link is a username in the URL, it is guessable. If the link works for 30 days, it is replayable. Both are launch-blockers.

Score yourself: 4/4 = ready. 3/4 = probably ready, document the gap. 2/4 or below = launch-blocked for any app with login.

Section 6: Fulfillment and delivery claims

Vibe-coded apps frequently over-promise on what the system actually does. "AI-powered insights" may be a static chart. "Real-time sync" may be a 24-hour cron. The risk is not legal exposure from these claims (it can be that too) — the risk is that the gap between claim and reality is the silent cancellation driver.

The 3 checks:

  1. Is every product claim in the marketing copy something the app actually does today? Read the landing page. Click every link. If a feature is described but missing, fix the copy before the feature.
  2. Is the "powered by" claim honest? "AI-powered" is fine if a real model call is happening. "AI-powered" is misleading if it is a static JSON lookup. The customer can tell the difference by the third interaction.
  3. Is there a stated delivery window for human actions? If you say "24-hour response" on a support form, do you have a system that surfaces new support requests within an hour? If the support request goes to a personal email you check weekly, the claim is not a claim, it is a future incident.

Score yourself: 3/3 = ready. 2/3 = fix the gap before any paid traffic. 1/3 or below = launch-blocked for any app that takes money or stores user data.

The 30-minute self-audit

Set a timer for 30 minutes. Walk the 6 sections in order, scoring yes/no per question. Tally the score.

Score bands:

  • 22-23 / 23: Ready for paid traffic. Keep the checklist; rerun before every major change.
  • 17-21 / 23: Probably ready. The 1-3 gaps are fixable in a half day. Fix them, then launch.
  • 12-16 / 23: Not ready. The gaps compound. Pick the 3-5 highest-blast-radius gaps and fix them before any traffic that could be regulated (EU, CA, NY, healthcare-adjacent, financial-adjacent).
  • 0-11 / 23: Not ready. The app is not safe to take real user data or real money. Either do the work, or pause the launch.

The bands are deliberately conservative. A vibe-coded MVP does not need to be a SOC 2-certified enterprise SaaS. It does need to be safe enough that a single user using the app does not get hurt.

When a self-audit is not enough

Three situations where a 30-minute self-audit is the right floor, not the ceiling:

  1. You are about to take EU traffic. EU AI Act Article 17 (quality management system for high-risk AI), the GDPR enforcement wave of 2025-2026, and the Colorado AI Act (enforceable June 2026) all add a layer that the 30-minute audit does not cover.
  2. You are about to take regulated data. Health, financial, education, employment, government, biometric, or children's data all move the app into a category where a self-audit is a sanity check, not a compliance pass.
  3. You have already had an incident. If the app has been live and a user filed a complaint, a chargeback, or a "delete my data" request you could not fulfill, the 30-minute audit is the start of a longer conversation, not the end of one.

A human forensic read of the live app is the next step in each of these cases. It is not a pentest, not a certification, not a legal opinion, and not a compliance attestation. It is a 1-day, evidence-based triage of the launch-safety gaps the checklist surfaced, plus the ones the checklist missed.

Sources

If the 30-minute audit surfaced more gaps than you can close this week, that is normal. The $99 vibe-coded launch safety audit is the human read of those gaps, with a redacted sample report so you can see the shape of the deliverable before you commit. Link: https://www.miloantaeus.com/vibe-coded-launch-safety-audit.html.

Top comments (0)