Vibe coding best practices: a production-ready checklist

What "production ready" means

Production is the live copy of your app, the one real customers use. Production ready means that when something goes wrong there, and sooner or later something will, the damage stays small, you hear about it fast and you can undo it.

I've spent 15 years in software and I'm now CTO at DeVmand. With AI agents, my build times fell from a month to two days. This list didn't get shorter. Vibe coding, building an app by describing it to an AI agent, means nobody read every line. So each check below is proved by a test, a setting or an alert, not by reading code.

This list is the short version of my 16-chapter playbook. This site was built with Claude Code, with those rules in its CLAUDE.md.

1. Code and tests

Skip this, and each new feature can quietly break an old one. Your customers find it first.

• The code is in Git from the first line, on GitHub or Bitbucket, so every change is saved and can be undone (playbook 08 · release).
• The main branch, the version that goes live, is locked: every change, the AI's too, arrives as a pull request (a proposed change, checked first) that a person approves (playbook 08 · release).
• A failing test, or coverage under 99%, stops the release: coverage is the share of code the tests run, so almost nothing ships untested (playbook 12 · tests).
• A browser test walks the main customer journey and records a video, so you see what customers see without clicking through yourself (playbook 12 · tests).

2. Security

Skip this, and customers can open each other's records, or a stranger finds your keys (the passwords your app uses for other services) and uses them. For vibe coding security, I'd start here.

• Each customer sees only their own data, and a test proves it for every page: if changing a number in the address bar opens someone else's order, that's a data breach (playbook 01 · system design).
• Every page states who may use it (anyone, signed-in users, admins), and one that doesn't stops the app from starting, so no check gets forgotten (playbook 15 · security).
• Sign-in and card payments are bought, not built: a sign-in service and a payment provider hold the passwords and card numbers, so your servers never do (playbook 01 · system design).
• Keys live outside the project folder, never in a .env file, and your AI agent can't read them: what it reads can end up in a chat (playbook 03 · folders).
• Test shortcuts can't reach production: if a fake payment or a "sign in as anyone" link is on in the live copy, the app refuses to start (playbook 01 · system design).
• What users type and what your AI returns never runs as code or a database command, and your AI's instructions hold no secrets: users can read and override them (playbook 15 · security).
• Every account behind the app belongs to one person and has two-factor sign-in (a code from your phone on top of the password): cloud, domain, Git host, payments, email (playbook 15 · security).
• A data-leak plan is written and rehearsed before launch: block access, sign everyone out, change every key. Under GDPR, the regulator may need to hear within 72 hours (playbook 15 · security).

3. Data and backups

Skip this, and one bad command, bug or intruder can erase your customers' data for good.

• The database is managed by your cloud provider, with point-in-time recovery: it can be rewound to any minute, at least 14 days back, and deletion protection is on (playbook 07 · prod).
• Nightly backups go to another account in another region, locked against deletion for three years, so an intruder in your cloud can't wipe them too (playbook 07 · prod).
• A restore drill runs every month into a throwaway database, with the time it took written down: a backup nobody has restored is only a hope (playbook 07 · prod).
• Money is stored as whole cents, never in a format that rounds, and each payment is saved together with its balance change or not at all, so balances always match (playbook 01 · system design).
• Test copies hold made-up data, never real customers' personal data: a leak from a test copy is still a leak (playbook 06 · stage).
• Customers can export and erase their data within a month, as GDPR requires, and a privacy page says what you keep, why and who gets it (playbook 01 · system design).

4. Running it: logs and alerts

Skip this, and your customers are your monitoring: you hear about a failure when someone writes to complain.

• The app keeps a log, a diary with one structured line per request, so "it broke at 3 pm" leads to the exact request and error (playbook 04 · logs).
• Logs hold ids only, never passwords, keys, emails, names or what users type: logs travel to dashboards, alerts and AI tools (playbook 04 · logs).
• Alerts reach you in a chat, Slack or Telegram, for errors, failing requests, a stopped background job, a missing backup or an expiring padlock certificate (playbook 10 · alerts).
• A check from outside your servers opens the site every minute, because a server that's down can't raise the alarm itself (playbook 10 · alerts).

5. Releases

Skip this, and every update is a bet, and undoing a bad one is guesswork.

• A stage copy runs every release first: a rehearsal copy with test payment accounts, so a broken release breaks there, not in front of customers (playbook 06 · stage).
• Customers get exactly the build you tested, moved from stage to production, never rebuilt in between (playbook 08 · release).
• Releases go out the same scripted way every time, ideally from a build server and never by copying files by hand, after the same checks, including scans for leaked keys and known security holes (playbook 08 · release).
• Undo is one command: deploy the previous version. Database changes only add, and old parts are removed a release later, so going back loses no data (playbook 08 · release).
• Updates run on a schedule: the outside code and tools your app uses, monthly, plus a weekly scan of the live version for newly found holes (playbook 08 · release).

6. Costs and limits

Skip this, and one user, one bot or one bug in a loop can run up your bills with no ceiling.

• Every action except reading has a rate limit, a cap on how often one user can repeat it per minute and per day, so no script can repeat it endlessly (playbook 16 · rate limits).
• Sign-up, login and contact forms are capped per IP address (the address a visitor connects from), so bots can't guess passwords or flood you with fake accounts (playbook 16 · rate limits).
• Every AI feature has a cap per user and one for all users together, so neither one heavy user nor everyone at once can spend past your budget (playbook 16 · rate limits).
• Every AI call has a money ceiling: its cost is reserved from the budget before the call, and question and answer length are capped (playbook 01 · system design).
• AI spend is logged per call, and an alert fires when hourly spend passes your budget, so you see the bill grow today, not at month end (playbook 10 · alerts).

How to use this checklist

Don't try to tick everything this week. Start with what protects your customers' data and money: group 2, security, and group 3, data and backups. Then fix one group a week.

For each open box, ask your AI agent to fix it and to show proof, not a yes: the test that fails without the fix, the alert arriving in your chat, the restore that worked. Done means shipped and checked.

The chapter in brackets holds the full rule, and with the playbook installed as a skill your agent can read it first. Keep open boxes as tasks in a tracker, not in the chat: the agent forgets between sessions (playbook 11 · tasks).

Next: put these rules in your CLAUDE.md. Building with Codex? See the playbook for Codex. All guides: articles.