The Vibe-Coded App Production Checklist
An app that works in a preview has passed one test: the path you clicked. Before real users, verify seven things that a preview cannot show — server-side authorization, secret handling, loading-empty-error states, dependency hygiene, reproducible deployment, automated tests and an independent audit. Each item below states the check, how to run it and what a failure looks like. This is Vibrr's engineering guidance and applies to any AI coding tool.
Vibrr is an independent product. It is not affiliated with, endorsed by or sponsored by Lovable, Cursor, Claude Code and Replit. Product names are trademarks of their respective owners and are used here only to describe compatibility and content.
Why a preview is not evidence
AI coding tools are optimised to produce something that looks finished. Claude Code's own documentation names the resulting risk: a plausible-looking implementation that does not handle edge cases, and it recommends never shipping what you cannot verify. The same holds for any tool. The checklist below is the difference between an app that appears to work and one you have tried to break.
2. Secrets never reach the client or the repository
Check: search the built client code and the repository history for keys, tokens and passwords. Failure looks like: any credential-shaped string. Rotate anything that was ever pasted into a prompt, committed, or exposed to the browser.
3. Loading, empty and error states exist
Check: force each state for each data-dependent view — throttle the network, empty the data, make a request fail. Failure looks like: a blank screen, a spinner that never resolves, or a raw error message.
4. Dependencies are known and current
Check: list direct dependencies, remove unused ones, and run your package manager's audit command. Failure looks like: packages you did not choose and cannot explain, or known vulnerabilities with an available fix.
5. Deployment is reproducible from the repository
Check: clone into an empty directory and follow only the README to build and deploy a preview. Failure looks like: a step that works only because of state that exists in the tool that generated the project.
6. Automated tests run with one command — and you have read them
Check: run the test command and read what the tests actually assert. Failure looks like: tests that pass because they assert nothing, or that mirror the implementation's mistakes. Tests written by the system that wrote the code are a useful signal but not an independent one.
7. An independent reviewer has read the result
Check: review the change against the acceptance criteria you wrote before building, using a reviewer that did not write it — a person, a fresh session, or an audit tool. Claude Code's documentation recommends exactly this pattern: a reviewer in a fresh context sees only the diff and the criteria, not the reasoning that produced the change. Failure looks like: a requirement that is silently missing.
How to sequence the seven checks
Run them in the order in which a failure is both most likely to be hidden by a preview and most expensive to discover late. Authorization and secrets first, because a failure there can invalidate everything built on top. States and dependencies next, because they are cheap. Deployment and tests follow, because they prove the earlier fixes are repeatable. The independent review comes last so the reviewer sees a stable result rather than a moving one.
| Check | Typical severity if it fails | Launch decision |
|---|---|---|
| Authorization | Critical | Do not launch |
| Secrets | Critical | Do not launch; rotate the credential |
| States | Medium | Launch only if the failing state is rare and non-destructive |
| Dependencies | Varies with the vulnerability | Fix known-exploitable issues first |
| Reproducible deploy | High for a team, lower for a solo prototype | Fix before the second person touches it |
| Tests | Medium | Acceptable to launch with gaps you have written down |
| Independent review | Varies | Triage findings; do not ignore critical or high |
The severities are a starting point, not a standard. Adjust them to what the app protects: a public marketing site and a payments dashboard should not share a rubric.
Where to go next
If your app handles accounts or private data, read the security audit guide next. For a platform-specific version of this checklist, see taking a Lovable app to production; other platforms are covered in the platform guides.
Frequently asked questions
What should I check first?
Authorization. It is the check most likely to reveal a serious problem and the one a preview is least able to show.
Does this apply to every AI coding tool?
Yes. It is written to be platform-independent: it tests the delivered app, not the tool that produced it.
Can Vibrr guarantee my app is production-ready?
No. A checklist and an audit reduce risk; they do not certify correctness.
Official and primary sources
- Best practices for Claude Code — Anthropic, read 2026-09-18