The Production-Readiness Checklist for Vibe-Coded Apps

The prototype is most dangerous right after the demo works. Everyone can see the magic. Nobody has yet watched the model time out, retry a payment twice, expose another user's row, or spend a week's API budget in one background job.

That is the point where builders usually add features. The better move is colder: pause, pick the one workflow that would create the most trust damage if it failed, and run it through a production gate. Not a platform. A gate. OpenAI's rate-limit guidance points to bounded retry and backoff. OpenAI's safety guidance points to adversarial testing and human review on risky paths. LangSmith separates offline evals before release from online checks on live traces. Supabase says RLS must be enabled on exposed tables. Those are not enterprise rituals. They are the minimum answers a small AI app needs before users bring real data.

I would keep this article as the front door for the pivot because it sets the editorial contract: the site is not about prompting tricks, tool lists, or celebrating speed. It is about the work that starts when the first user depends on the output. The rest of the corpus can point back to this gate.

A useful gate has one job: it turns hidden uncertainty into named blockers. The question is not whether the application feels polished. The question is whether the builder can explain what happens when the model is slow, wrong, unavailable, over budget, or unsafe. If the answer is a shrug, the product is not ready for real users.

The gate should be run against one workflow at a time. Pick signup, checkout, document generation, import, onboarding, or the agent action that mutates customer data. Draw the path from user action to model call to tool call to storage write to user-visible result. Then ask the same questions at each boundary: what can fail, who sees it, what gets retried, what gets logged, what can be rolled back, and what data is exposed.

The small-builder trap is treating this as paperwork. It is not. The gate produces tests. A missing timeout becomes an integration test around a fake slow provider. A missing data boundary becomes a second-user RLS test. A missing prompt guard becomes an eval case. A missing cost answer becomes per-workflow usage logging. The artifact is not a checklist screenshot. The artifact is a set of checks that fail when the app regresses.

The first run of this gate will produce more misses than a solo builder wants to see. That is normal. The useful move is to rank misses by user harm, not by how easy they are to patch. Data exposure and non-idempotent actions sit at the top because a bad retry can create irreversible damage. A wrong answer with a clear correction path is lower. A missing animation is not on the same list.

Security boundaries usually outrank model quality. A mediocre answer is embarrassing. A leaked table is a breach. Supabase's current RLS guidance is blunt: RLS must be enabled on tables in an exposed schema, and client access should use a publishable key governed by policies. The same pattern applies outside Supabase. Browser code can hold public credentials. Server code holds secrets. The model never receives data it does not need for the task.

After data boundaries, inspect actions that mutate state. Retrying a read is annoying when it fails. Retrying a charge, email send, reservation, or account deletion can create real damage. The launch gate should force non-idempotent operations to name their idempotency key, rollback path, and failure copy. If the workflow cannot answer those questions, it should not ship.

This gate is deliberately small. It does not replace incident management, security review, data governance, or model-risk work for regulated systems. It gives a builder the first defensible line between a demo and a product. That distinction matters because the earliest users do not care that the app was built quickly. They care whether their work disappears, leaks, doubles, or costs them money.

The gate also gives the rest of the team a shared vocabulary. Reliability owns failure states and recovery. Evals own behavioral regressions. Security owns data boundaries and unsafe actions. Cost owns usage patterns. In a one-person project those owners may be the same human, but the categories still matter. They stop the builder from hiding every problem under the label 'AI quality'.

The non-obvious benefit is editorial. Once this gate exists, every article in the corpus can answer the same reader question: which production risk does this reduce, and what evidence proves it? That is why this article should stay. It is the map for the pivot.