From vibe coding to production

I am not going to be sniffy about vibe coding. I use it. Describing an app and having it exist an hour later is a genuine change in what a small team can attempt, and pretending otherwise is posturing.

The trouble is the last mile. A prototype has to be right once, for you, with data you chose. A product has to be right every time, for strangers, with data they chose. Here is the pass that closes that gap.

Day one: the data model

Everything else is recoverable. A wrong schema poisons every feature built on top of it, and by the time you notice, real rows exist.

• Constraints where they belong: not-null, unique, foreign keys. Generated prototypes lean on application logic and skip these constantly.
• Money as integers or decimals, never floats. Timestamps with timezones, always.
• A plan for edits and deletes. Prototypes assume inserts. Reality is corrections.
• Row-level access rules enforced in the database, not filtered in the client. This is the most common serious flaw I find.

Day two: auth, permissions, and validation

Prototypes hide behind obscurity. Real apps get poked. Verify sessions server-side on every protected path, check permissions per record rather than per page, and validate every input at the boundary with a schema rather than trusting the form that produced it.

Roles belong in their own table, checked server-side. Roles stored on a profile row that a client can update are a privilege escalation waiting for someone curious.

Day three: failure and money

1. Every external call gets a timeout and a retry with backoff. Prototypes assume the network works.
2. Errors reach you, not just the user's console. One error reporter, one channel someone reads.
3. Rate limits on anything expensive or public, and idempotency keys on writes triggered by webhooks.
4. If AI calls are involved, per-run token caps and a daily spend ceiling. The failure mode is a loop, not an outage, per cost control.

Day four: tests on the paths that matter

Not coverage targets. Tests on the money paths: signup, payment, the core action, and permissions. If your app has AI behavior, an eval suite matters more than unit tests, because that is where silent regressions live.

Agent-generated tests need reading rather than trusting, for the reasons in how to review agent-written pull requests.

Everything worked. Two customers could see each other's invoices, because the filter was in the front end.

Day five: know what is happening

• Uptime check on the real user path, not the health endpoint.
• Error rate and latency, visible on one screen.
• Spend per day with an alert below the ceiling.
• A basic funnel, so you learn whether anyone completes the core action.

What not to do

Do not rewrite. The prototype encodes real understanding of the problem, and a rewrite discards that in exchange for a cleaner directory structure. Harden in place, one module at a time, starting with whatever real usage touches most.

And do not add architecture for scale you do not have. Queues, caches, and service splits solve problems you can measure. Until you can measure them, they are just more things that can break.

The list, in order

1. Data model, constraints, and database-enforced access rules.
2. Server-side auth, per-record permissions, schema validation.
3. Timeouts, retries, error reporting, rate limits, spend caps.
4. Tests on the money paths, evals on AI behavior.
5. Uptime, errors, spend, and one funnel metric.

That is a week, and it converts something impressive into something you can charge for. If you would rather have it reviewed by someone who has done it repeatedly, the AI production readiness audit covers exactly this ground, and the work shows what came out the other side.

Frequently asked