Is Your AI-Built App Safe to Launch? A 12-Point Production Checklist

The demo worked. You posted a screen recording, woke up to 340 signups, and by lunchtime someone in your Discord had changed a single number in the URL — from /orders/1042 to /orders/1041 — and was staring at a stranger's order: their name, their address, the last four digits of their card.

That is the exact moment most founders learn that "it works" and "it's safe to put in front of real people" are two completely different claims. AI coding tools — Lovable, v0, Bolt, Cursor, Replit — are astonishingly good at the first claim. They will hand you a working app in a weekend. They are, by design, optimizing for the demo, not for the day 200 strangers arrive with real data and the occasional bad intention.

Below is the checklist we run through when someone hands us an AI-built app before launch. Twelve items, ordered roughly by how often each one is the reason we send back a "do not ship yet" note. None of them require rewriting your app. Most are a few hours of focused work once you know they're the problem.

TL;DR — Key Takeaways

• Authorization is the number-one killer. AI tools hide buttons from users but rarely enforce permissions on the server. Hiding a button is not security.
• IDOR is everywhere. If your URLs contain sequential IDs, assume someone will change them — and check whether your API actually stops them.
• Secrets leak client-side. An API key in your browser bundle is a when, not an if.
• Payments need verified webhooks, not just a success redirect. A redirect can be faked; a signed webhook can't.
• LLM features add a new attack surface — prompt injection and runaway token bills — that older checklists never mention.
• Almost all of this is checkable in an afternoon and fixable without a rebuild. That is exactly what a production-readiness audit is for: finding these before your users do.

Why "it works" and "it's safe" are different questions

A demo is a happy path. One user, doing the thing you designed, with data you control. Production is the opposite: many users, doing things you didn't design for, with data you've never seen, some of them actively poking at the edges to see what falls out.

AI code generators are trained to make the happy path work. Ask for "a dashboard where users can see their invoices" and you'll get exactly that — a dashboard that shows invoices. What you won't reliably get is the invisible half of that sentence: only their own invoices, enforced on the server, checked on every request, even when someone forges the request by hand. That gap between the visible feature and the invisible guarantee is where nearly every launch-day incident lives.

The good news is that the gap is finite and well understood. You are not looking for exotic zero-days. You are looking for a short list of missing checks that show up again and again in generated code. Here is that list.

The 12-point production-readiness checklist

1. Server-side authorization on every route. Hiding an admin button in the UI does nothing if the /api/admin/* endpoint behind it still answers anyone who calls it directly. Every protected route must check "is this user allowed to do this?" on the server, every time.
2. Data isolation between users (IDOR). For any record fetched by ID, confirm the record belongs to the logged-in user before returning it. This is the /orders/1041 problem, and it's the single most common flaw we find.
3. Secrets out of the client bundle. Stripe secret keys, database URLs, LLM API keys — none of these belong in frontend code or NEXT_PUBLIC_ variables. Open your deployed site, view source, and search the bundle for sk_ and key.
4. Input validation on the server. Client-side validation is a UX nicety, not a defense. Every endpoint should validate and type-check its input (Zod, Joi, or equivalent) before it touches your database.
5. Rate limiting on anything expensive. Login, signup, password reset, and any endpoint that calls an LLM or sends email. Without limits, one script turns your app into a very expensive denial-of-service target — sometimes against your own cloud bill.
6. Payments verified by webhook. Never mark an order paid because the browser landed on your /success page. Confirm payment from a signed Stripe (or similar) webhook, with the signature actually verified.
7. Error handling that fails closed. When something breaks, the app should deny access and log the error — not fall through to an open state or dump a stack trace with your database schema to the user.
8. No secrets or PII in logs. Logging the full request body is convenient until you're storing plaintext passwords and card details in a log aggregator forever.
9. CORS and cookies configured deliberately. A wildcard Access-Control-Allow-Origin plus credentialed cookies is a combination worth understanding before it ships, not after.
10. Dependencies with known CVEs pinned or patched. Run npm audit (or your ecosystem's equivalent). You don't have to fix every advisory, but you should know what's there.
11. Prompt-injection defenses on LLM features. If untrusted user text reaches a model that can call tools or read private context, assume someone will try to talk it into misbehaving. Separate instructions from data, and constrain what the model is allowed to do.
12. Cost guardrails on AI and infra. Token budgets, caching, and per-user limits on model calls. The failure mode here isn't a breach — it's a $4,000 bill from a loop you didn't notice for three days.

Severity: what to fix before launch vs. what can wait

Not everything on that list blocks a launch. Triage matters — spending a week hardening a feature ten people will use, while a data-isolation hole sits open, is the wrong order. Here's how we tend to rank them.

Issue	Real-world consequence	When to fix
Missing server-side authorization	Any user acts as any other user, or as admin	Before launch — blocking
IDOR / broken data isolation	One user reads or edits another's data	Before launch — blocking
Secrets in client bundle	Keys stolen, fraudulent charges, data access	Before launch — blocking
Unverified payment success	Free access to paid features	Before taking money
No rate limiting	Abuse, spam, surprise cloud/LLM bills	Before launch — high
Missing monitoring	You hear about outages from angry customers	First week — high
Unpinned vulnerable dependency	Depends entirely on the specific CVE	Assess, then decide

A concrete example: the $3,900 weekend

A founder we worked with launched an AI-built SaaS on a Thursday. The app let users generate marketing copy — each generation calling an LLM behind an unauthenticated, unthrottled endpoint. By Saturday, someone had found the endpoint, written a ten-line script, and pointed it at the model in a loop. There was no per-user limit and no caching, so every call was a fresh, full-price request.

The bill was $3,900 before anyone noticed. Two changes fixed it permanently: require a logged-in session to hit the endpoint, and cap each account at a sane number of generations per hour with a short cache on identical prompts. Total work: under a day. The lesson wasn't "AI code is bad" — the app was genuinely useful. The lesson was that the useful part shipped and the guardrails didn't, because nobody had a checklist telling them the guardrails existed.

Where to go from here

Run the twelve points against your own app this week. Start at the top: open your deployed site, log in as a test user, and try to reach another test user's data by editing an ID. If you can, you've found your first blocker. Work down the list from there, and use the severity table to decide what genuinely blocks launch versus what you can schedule for week one.

If you'd rather have a second set of eyes — specifically, senior engineers reading the actual code by hand rather than pasting scanner output into a template — that's the service we run at Hyvo. A production-readiness audit gives you every finding with its severity, its real-world consequence, and a concrete fix, in priority order, so you know exactly what to do before launch. And if the report turns up more than you want to fix yourself, the same findings become the scope for a fixed-price plan to turn the prototype into a production build — no vague hourly quotes, no rebuild-from-scratch reflex.

Either way, the goal is the same: find out what breaks before your users do, while it's still a checklist item and not an incident.