Vibe Coding to Production: The Eight-Item Checklist

A vibe-coded app is ready for production when it passes eight boring checks. The list: auth enforced on the server, data you own and can export, versioned migrations, error visibility, hard cost ceilings, abuse protection, a restore-tested backup, and proof that you did not spend launch week polishing the marketing site. None of these are glamorous. All of them are cheaper to do before your first paying user shows up than after.

I built GiveFeedback.dev solo in six weeks during Lovable Shipped Season 1, won the $100K grand prize against roughly 5,800 builders, and had paying clients before the prize closed. That sounds clean when you compress it into one sentence. The six weeks were rough, and this checklist exists because of exactly where they got rough. It is the list I would hand myself on day one.

A note on scope before we start: this is for apps that will hold other people's data and take other people's money. If you built a personal tool or a prototype for a demo, ship it and enjoy your evening. The moment a stranger's credit card or a client's records enter the picture, the rules change.

1. Auth: assume the scaffold is decorative#

AI tools generate auth that works on the demo path: sign up, log in, see your dashboard. What they routinely skip is enforcement on the server. If your access checks live in React state, anyone who opens the network tab and replays a request can read someone else's rows.

So before launch I verify three things by hand. Every API route and database query checks the session server side, with row-level security if you are on Supabase and middleware if you are not. Password reset sends, expires, and cannot be replayed. Roles are enforced where the data lives, not where the buttons render. The caution is earned: Veracode's 2025 GenAI Code Security Report found that AI models introduced security vulnerabilities in 45 percent of its test tasks. Broken access control is the classic offender, and the tool will happily hide a button from non-admins and call that authorization.

2. Data ownership: know how you would leave#

Before you charge anyone, answer two questions in writing: where does the data physically live, and how do you get all of it out. On most vibe-coding stacks the database is a managed Postgres you can connect to directly, which is genuinely good news, but confirm it rather than assume it. Run a full export. Open the dump. Check that files and uploads are in a bucket you control, not buried in the platform.

The moment a client pays you, their data becomes your liability. "The platform probably has an export button" is not an answer you want to be giving during an incident or an acquisition conversation. The same question decides how painful your exit will be later, which is a whole topic on its own (migrating off Lovable covers it).

3. Migrations: version the schema before real data exists#

Conversational building mutates the schema conversationally. That is fine while every table is disposable. The day a paying user's rows land in the database, an untracked schema change becomes a loaded weapon. The AI helpfully renames a column during an unrelated fix, and production writes start failing while you are asleep. The fix is to adopt versioned migrations on the day you decide the product is real, not on the day you need to alter a table that has data in it. The habit costs maybe an hour to set up. Retrofitting it after a bad change costs a weekend, plus some customer trust you will not get back at the same price.

4. Observability: you will not be watching#

A vibe-coded app fails silently by default. No error tracker, no structured logs, no uptime check. That means your first monitoring system is a customer emailing to say the thing is broken. The minimum bar before launch: an error tracker wired to both client and server, one uptime ping on the endpoint that matters most, and logs you can search rather than scroll.

The reasoning here is plain arithmetic. Solo builders sleep, and users arrive in time zones you do not. If the app breaks at 3 a.m. Toronto time, I want an alert on my phone, not a churned customer and a mystery. Ten minutes of setup buys you the difference between "we saw it and fixed it" and "we found out from a refund request."

5. Cost ceilings: decide your worst day in advance#

If your app calls an LLM, a maps API, or anything metered, one infinite loop or one determined abuser can spend a month's budget overnight. Three moves, in order of importance. Set hard caps at the provider level (caps, not just alerts). Rate-limit per authenticated user rather than per IP. Decide the specific dollar number at which you would rather the feature go down than keep paying. Alerts wake you up after the money is gone. Ceilings mean the blast radius is a support ticket instead of an invoice. This item feels optional right up until the first time a usage graph goes vertical, and by then the money is already spent.

6. Abuse: the internet finds public forms in days#

Any public input surface, a signup form, a comment box, a feedback widget, gets discovered by bots shortly after your site is indexed. GiveFeedback is literally a feedback product, so the entire surface area is strangers writing into my database. That forced a posture I now recommend regardless: treat every unauthenticated input as hostile by design. Rate limits on submissions, a captcha-class challenge (Turnstile is free and unobtrusive) on anything public, server-side validation and length caps, and no raw user content rendered without sanitization. The general rule: if a stranger can write to your database, assume a script will try ten thousand times, because sooner or later one will.

7. Backups: an untested backup is a hope#

Managed databases mostly back themselves up, which lulls people into skipping this. But the backup is not the deliverable. The restore is. The check that matters: have you ever recovered your database to a point in time, and do you know how long it takes? Do it once before launch, with a timer running. You learn three things at once: your real recovery time, whether the backup is complete (files and buckets included), and whether you can execute the procedure calmly. The alternative is learning all three during the incident itself, in front of the customers it affects.

8. The marketing-site trap#

This is the one that nearly got me. During the Shipped sprint, the GiveFeedback marketing site won a priority fight it should not have won, and I nearly shipped a week late because of it. The trap is that the work feels like progress. It is visual, it demos beautifully, and AI tools make it seductively fast to iterate on, so every session ends with something prettier. But the product earns the money; the site just introduces it. At launch, one plain page with a clear sentence and a working signup beats a gorgeous site fronting an unfinished app. My rule now: timebox the site to a day, and it does not get that day until the seven items above are green.

What this checklist is really testing#

The honest lesson from those six weeks: I went in assuming the speed was mine and the tool was a multiplier, and I underestimated how much of it ran the other way. Vibe coding compresses the build. It does nothing to the judgment. Every item on this list is a decision the tool will not make for you. The tool optimizes for the demo working today; production is the art of things still working in month three. Eight years of shipping software into hospitals taught me that the unglamorous checks are the product; the competition just confirmed it under a clock. The longer version of that argument, prize money and all, is in the GiveFeedback case study.

If you are mid-sprint on an AI-built product right now, run the list top to bottom and fix whatever is red; most items are an afternoon, give or take. If you are a founder trying to get a vibe-coded product to real revenue and want hands-on help rather than advice, that is one of the engagement shapes I run. A call makes sense once you know which items on this list scare you.