Vibe-coded to production: a technical checklist

“Vibe coding” — building fast with AI, following the flow, shipping what works — is a genuinely good way to get to a working app. It's a terrible way to get to a safe one, because the tools optimize for the happy path and stay quiet about everything that only breaks under real load. This is the checklist we run every incoming rescue against. Work through it on your own build and you'll find most of the landmines before they go off.

Authentication and authorization

• Sessions are validated on the server on every protected request — not just checked once in the frontend.
• Authorization is enforced server-side: a user can never access or modify another user's data by changing an ID in a request.
• Password reset, email verification, and session expiry actually work and can't be bypassed.
• Admin routes and internal tools are genuinely protected, not just hidden.

Secrets and configuration

• No API keys, database URLs, or tokens are committed to the repo — check the git history, not just the current files.
• Secrets live in environment variables / a secrets manager, and any key ever exposed has been rotated.
• Nothing sensitive is shipped in the client bundle where anyone can read it.

Data and backups

• Automated database backups are on — and you've tested restoring one, so you know it works.
• Destructive operations are guarded and reversible where they can be.
• Personal or sensitive data isn't leaking through logs, error messages, or public endpoints.

Input validation and error handling

• Every input from a user or external system is validated at the boundary before it's trusted.
• External API calls have timeouts and fallbacks, so one slow or failed dependency can't take the whole app down.
• Errors are caught and handled — users see a graceful message, not a stack trace, and the app doesn't crash.

Observability

• Error tracking is wired up, so you see real exceptions instead of waiting for a customer to report them.
• Uptime and basic performance monitoring alert you before users notice an outage.
• Logs exist and are useful enough to actually debug a production issue.

Deploys and environments

• There's a real distinction between production and a staging/preview environment — you're not testing on live.
• Continuous integration runs on every change, so broken code is caught before it ships.
• Deploys are repeatable and reversible; you can roll back quickly when something goes wrong.

Performance and security basics

• Obvious N+1 queries and unbounded data loads are handled before they meet real traffic.
• Rate limiting protects expensive or abusable endpoints.
• The common web vulnerabilities — injection, XSS, insecure direct object references — have actually been checked, not assumed.

How to use this list

You don't need every box ticked to launch, but you need to know which ones aren't — and to have made that call deliberately. The danger with vibe-coded apps isn't that they skip these; it's that no one ever decided to skip them. If you can't confidently check most of the authentication, secrets, and data sections, that's not a backlog item — that's the thing standing between you and a bad day.

The demo tested whether the app can work. This list tests whether it can survive being used. They're different questions, and only one of them matters once real users arrive.

If you'd rather not run this checklist alone, a fixed-price audit does exactly this: a written read of where your build stands against every line above, what's risky, and what it costs to close the gaps — yours to keep whatever you decide next.