Shipping2 min read
From prototype to production: a pre-launch checklist for vibe-coded apps
The prototype works. Before real users arrive, there is a short list of things that separate a demo from a product, and most of them take an afternoon.
Key takeaways
- Separate development and production data and credentials before anything else.
- Make every deploy previewable and every release reversible.
- Set security headers, CORS, and rate limits once, at the edge or in middleware.
- Add logging and error alerts before launch, not after the first incident.
- Test the deployed app as an anonymous visitor and as a second user.
1. Separate your environments
Prototypes often run against one database with one set of keys. Before launch, split them:
- A production database that no development tool or agent session can write to.
- Separate API keys for production, with the narrowest scopes the provider allows.
- Secrets stored in your host's environment settings, never in the repository or the client bundle.
- Test accounts that exist only outside production.
2. Previews and rollbacks
Every change should be deployable to a preview URL before it reaches users, and every production release should be one click from reverting. Most modern hosts give you both. Make sure preview deployments use preview data, not production data, and are not publicly indexed.
3. Headers, CORS, and rate limits
In Tenzai's test, none of the 15 agent-built apps set standard security headers and 14 had no login rate limit. These are cheap to fix in one place:
- Security headers: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, and frame protections. Start from the OWASP cheat sheet.
- CORS: allow your own origins explicitly. Never reflect the request origin with credentials enabled.
- Rate limits on login, signup, password reset, and any route that sends email or costs money.
4. Dependencies
Read through the packages your agent added. Confirm each one exists, is the package you expected, and is actively maintained. Models occasionally suggest package names that do not exist, and attackers register those names. Pin versions and turn on your host's dependency alerts.
5. Observability
- Structured server logs you can search by user and request.
- Error tracking with alerts to a channel someone reads.
- Uptime checks on the home page and one authenticated route.
- Logs that never contain passwords, tokens, or full card numbers.
6. Test access control on the deployed app
This is the step the research says matters most. Use the deployed app as a normal user, then replay what it does as an anonymous visitor and as a second account. Anything that answers when it should refuse is a launch blocker. See what the research shows for why.
7. Make sure people can find it
Launch is also when search and answer engines first meet your site. Check that your pages render meaningful HTML without JavaScript, and that robots.txt is not blocking the crawlers you want. See Is your app invisible to AI crawlers?
Routelint records the API calls your running app makes, then replays them with no session and as a second account. One scan needs no account.
Sources
- Vibe coding tested: AI agents nail SQLi but fail miserably on security controls — SecurityWeek
- HTTP Security Response Headers Cheat Sheet — OWASP Cheat Sheet Series
- The rise of the AI crawler — Vercel
Published November 1, 2026 by the Routelint team.