AI-Built Apps
The vibe coding production-ready checklist.
25 things to fix before your AI-built app meets real users — the work Lovable, Bolt, Replit, v0 and Cursor skip. Each one with the failure mode and the fix. Use it as a checklist; or have us run it against your app for free.
Contact form or book a free call
Free Technical Audit50+ Projects Taken OverFixed-Price · No Hourly Billing
25 checks across five categories
Vibe-coding tools are genuinely great at getting to a working demo. But "it runs on my screen" and "it's safe to put real users and real data on it" are very different things. Work down each category — the failure mode tells you why it matters, the fix tells you what to do.
Category 016 checks
Security
This is where AI-built apps fail hardest and most publicly. The CVE-2025-48757 incident left 170+ Lovable apps with their databases readable by anyone. Start here.
01
Row-level security / database authorization is ON
Failure: with RLS off, anyone who finds your API URL can read or edit every row — all users' data, not just theirs.
Fix: enable RLS on every table and write policies so a user can only touch their own rows. Default-deny, then allow.
02
Secrets are out of the client bundle
Failure: service keys, API tokens and DB credentials hardcoded into the frontend ship to every visitor's browser — readable in devtools.
Fix: move every secret to server-side environment variables. Only public, anon-safe keys belong in client code. Rotate anything that leaked.
03
Auth on every protected route
Failure: the UI hides the admin button, but the API endpoint behind it has no check — so anyone can call it directly.
Fix: enforce authentication and authorization server-side on every protected route and mutation, not just in the interface.
04
Input is validated server-side
Failure: trusting the client. Malformed or malicious input reaches your database and logic untouched, enabling injection and corrupt data.
Fix: validate and sanitize every input on the server with a schema (Zod or similar). Never trust anything the browser sends.
05
Rate limiting on public endpoints
Failure: login, signup, and AI/email endpoints can be hammered — credential stuffing, spam, and a surprise bill that drains your budget overnight.
Fix: add rate limiting and abuse protection to public and expensive endpoints. Cap per-IP and per-user request rates.
06
Dependencies are scanned
Failure: AI tools pull in dozens of packages you never reviewed; known CVEs sit in your tree silently.
Fix: run npm audit / Dependabot / Snyk, patch known vulnerabilities, and keep a habit of updating. Remove packages you don't use.
Want us to run the security checks against your app? It's free — 2–3 days →
Category 025 checks
CI/CD & deployment
Most vibe-coded apps ship by hand and hope. There is no safe way to deploy a fix at 2am and nothing stops a bad change from taking the whole app down.
07
Code is in version control
Failure: the source of truth is a chat thread or a single editor tab. One bad save and there is no history to roll back to.
Fix: get the code into Git with real commits. Now you have history, review, and a safety net for everything below.
08
Automated build that can fail loudly
Failure: builds happen on someone's laptop. 'Works on my machine' breaks the moment a different machine runs it.
Fix: a CI build that runs on every push — install, type-check, lint, build. If it's red, it doesn't ship.
09
A staging environment
Failure: there is only production. Every test is a live test, on real users, with real data.
Fix: a staging environment that mirrors production so changes get exercised before customers see them.
10
One-command or automatic deploy
Failure: deploys are a manual ritual of clicks and copied files — easy to half-do, easy to get wrong under pressure.
Fix: deploy on merge, or with a single command. Repeatable, boring, and the same every time.
11
A rollback plan
Failure: a bad deploy is live and there is no fast way back. You debug forward while users are down.
Fix: be able to roll back to the last good version in one step — instant revert or re-deploy of the previous build.
Want us to run the ci/cd & deployment checks against your app? It's free — 2–3 days →
Category 035 checks
Error handling & observability
When something breaks in production you should find out from an alert, not an angry user. Most AI-built apps fail silently and give you no way to see what happened.
12
Global error handling
Failure: one unhandled exception white-screens the whole app, or crashes the server, with no graceful fallback.
Fix: error boundaries on the frontend and a global handler on the backend so one failure is contained, not catastrophic.
13
Structured logging
Failure: no logs, or a wall of console noise you can't search. When it breaks, you're guessing.
Fix: structured, leveled logs with request context — so you can answer 'what happened to this user at this time'.
14
Error alerting (Sentry or similar)
Failure: errors happen in production and nobody knows until a customer complains — days later, untraceable.
Fix: wire up Sentry (or similar) to capture exceptions with stack traces and notify you the moment they happen.
15
Uptime monitoring
Failure: the app is down for hours overnight and the first you hear of it is the morning support email.
Fix: an uptime monitor that pings your app and alerts you the minute it goes down or slows to a crawl.
16
Meaningful user-facing error states
Failure: failures show a blank screen or a raw stack trace — users assume the product is broken and leave.
Fix: clear, human error and empty states with a way forward — retry, contact, or go back. Never a dead end.
Want us to run the error handling & observability checks against your app? It's free — 2–3 days →
Category 044 checks
Data integrity
Schemas generated to make a screen work, not to hold real data. This is the category that loses customer data quietly — and the one nobody checks until it's too late.
17
Schema constraints & migrations
Failure: no foreign keys, no NOT NULL, no uniqueness. Orphaned and duplicate records pile up and corrupt your reporting.
Fix: enforce constraints at the database level and manage schema changes through versioned, reversible migrations.
18
Automated backups
Failure: no backups, or backups nobody has ever configured. One bad query or outage and the data is simply gone.
Fix: automated, scheduled backups with sensible retention — running without anyone having to remember.
19
A tested restore
Failure: backups exist but have never been restored. The day you need one, you find out it was incomplete.
Fix: actually restore a backup into a fresh environment and confirm the data comes back whole. A backup you can't restore isn't one.
20
No destructive ops without guards
Failure: a delete with the wrong WHERE, or a migration with no safeguard, wipes a table in one shot.
Fix: soft deletes, confirmations, transactions, and migration guards so a single mistake can't be irreversible.
Want us to run the data integrity checks against your app? It's free — 2–3 days →
Category 055 checks
Scalability & maintainability
The prototype that got you here is the thing that now slows you down. It runs fine with 10 rows and falls over at 10,000 — usually right when traction starts.
21
A sensible data model with indexes
Failure: tables modeled to fit a screen, no indexes on the columns you filter by. Queries crawl as the table grows.
Fix: a data model built for how the data is actually queried, with indexes on lookup and join columns.
22
No N+1 queries or obvious bottlenecks
Failure: a list page that fires one query per row — fine at 10 items, a timeout at 1,000.
Fix: batch and join queries, paginate large lists, and cache the expensive ones. Remove the obvious hot paths.
23
Basic tests on critical paths
Failure: zero tests. Every change is a gamble and you only discover regressions when a customer hits them.
Fix: automated tests on the paths that matter most — auth, payments, signup — so changes can't silently break revenue.
24
Documented setup
Failure: nobody but the original tool can run the project. Onboarding a developer takes days of reverse-engineering.
Fix: a README that gets a new machine from clone to running — env vars, commands, and dependencies written down.
25
Code a new developer can read
Failure: thousands of lines no human wrote or reviewed, no structure. Adding the next feature means fighting the codebase.
Fix: refactor into clear modules with consistent patterns, so a developer who has never seen it can find their way.
Want us to run the scalability & maintainability checks against your app? It's free — 2–3 days →
Free Audit
Don't want to check 25 things yourself?
Send us your repo. We run this exact checklist against your code, database rules, and deployment, and hand you a written report — what's already fine, what's exposed, and what it costs to make production-ready. Free, 2–3 days, no obligation. You keep the report whether you hire us or not.
The bigger picture: our vibe code to production guide · what it costs to fix · hire a developer for your AI app
Frequently Asked
What is a vibe coding production-ready checklist?
It is the list of things an AI-built app needs before real users and real data touch it — but that vibe-coding tools skip because they optimize for a working demo. This page lists 25 of them across five areas: security, CI/CD and deployment, error handling and observability, data integrity, and scalability. For each one we give the failure mode (how it bites you in production) and the fix.
Why do vibe-coded apps break in production?
Because 'it works on my screen' and 'it is safe to put strangers and real data on it' are different problems. AI tools nail the first and ignore the second — database authorization is left open, secrets ship in the browser bundle, there is no deploy pipeline, no monitoring, and no backups. None of it shows up in the demo. All of it shows up the week you get traction.
How do I know which items on the checklist apply to my app?
Run the free audit. We review your codebase, database rules, and deployment, then hand you a written report mapped to this exact checklist — what is already fine, what is exposed, and what it costs to fix. You keep the report whether you hire us or not. 2–3 days, no obligation.
Can I fix these myself or do I need an agency?
Plenty of items here you can do yourself — turning on row-level security, moving secrets to environment variables, adding a Sentry DSN. Others (a data model that scales, real migrations, a tested restore, removing N+1 queries) need someone who has shipped production software before. The honest answer is in the audit: we will tell you what is a weekend of your time and what is not.
How much does it cost to fix everything on this checklist?
The audit is free. Security and hardening work runs ₹2L–₹12L fixed-price depending on how many of these 25 items are open and how deep the gaps go — security-only is the lower end, full hardening (security, CI/CD, monitoring, backups, data model) the upper. Full takeover and ongoing build is scoped after the audit. No hourly billing — you know the number before we start.
How many did you tick?
If the answer was uncomfortable, that's normal — vibe-coding tools leave most of these open. Get a free technical audit and we'll tell you exactly which of the 25 stand between you and production.
Contact form or book a free call
Related: Vibe code to production · AI code audit · Cost to fix a vibe-coded app · Hire a developer for your AI app