Vibe-Coded App to Production: A Security & Launch Checklist

A 10-step checklist for taking a vibe-coded app to production safely, covering secrets, auth, database rules, rate limits, backups, monitoring and handover.

By Innovixus Team · 2026-10-28

In short: A vibe-coded app is ready for real users only after ten checks: secrets out of the code, working login and permission checks, database access rules, input validation, rate limits (including for anonymous users), a dependency audit, tested backups, logging and alerts, safe error handling, and a named owner for the code and accounts. Most AI-built prototypes miss three or more of these, and fixing them before launch costs far less than fixing them after a leak.

A vibe-coded app is safe to launch when someone has checked the parts AI coding tools tend to skip: where the secrets live, who can read which data, what happens when a stranger hammers your endpoints, and who fixes it at 2 a.m. Tools such as Cursor, Claude Code, Codex, Lovable and Bolt make it easy to build a working app in a weekend. They do not decide for you who owns it, who reviews it or what happens when it breaks.

Below is the ten-step checklist we use when a founder or operations team brings us an AI-built prototype and asks, "Can we put real customers on this?" Work through it in order. The first four steps prevent most data leaks.

Why this matters now

Three things from this year show the problem is not hypothetical.

• Secrets in hosting platforms are a target. On 21 October 2026, Railway disclosed that an unauthorised party may have accessed customers' encrypted environment variables, in some cases decrypted, and asked all customers to rotate their secrets, according to BleepingComputer. The report says Railway linked the incident to a series of attacks on AI inference providers. If your OpenAI, Anthropic or Gemini key sat in that environment, someone else may be spending your credit.
• Many AI-built apps are left open. In May, security firm RedAccess said it had found about 380,000 publicly accessible apps and assets built with tools such as Lovable, Base44, Netlify and Replit, of which roughly 5,000 contained sensitive corporate data, as reported by Security Boulevard. Exposed data included hospital conversation summaries and a bank's internal financial information.
• Non-engineers are building internal tools. The Pragmatic Engineer reported on 8 October that companies such as Ramp and Stripe now run internal platforms where non-engineers build their own apps on top of company data.

We hear the same pattern closer to home. Developers in Indian tech communities describe founders shipping AI-written features and brushing off security questions as something to deal with later. SaaS founders report public chatbots being probed by visitors trying to extract hidden prompts and keys, or simply to run up the token bill.

The checklist

1. Secrets and API keys

Search the codebase and its git history for keys, passwords and connection strings. AI tools often paste a key straight into a file to make a demo work.

• No secrets in source code, front-end bundles or git history
• Every secret stored in environment variables or a secrets manager
• Keys that were ever committed have been rotated, not just deleted
• Separate keys for development and production
• Spending limits set on every AI provider and cloud account

Anything shipped to the browser is public. If the front end calls an AI model directly with your key, move that call to the server.

2. Authentication and authorisation

Login is authentication. Checking that user A cannot open user B's invoice is authorisation, and it is what AI-generated code most often gets wrong.

• Every API route checks the user is logged in
• Every route that reads or changes a record checks the user owns it or has the right role
• Admin pages are protected on the server, not just hidden in the menu
• Password reset, email verification and session expiry work as expected

A quick test: log in as one user, copy a URL or API request with a record ID, log in as another user and try it. If it works, you have a leak.

3. Database rules and row-level security

If you use Supabase, Firebase or a similar backend that the browser talks to directly, the database rules are your security. Supabase's own guidance is to enable row-level security on every table in an exposed schema.

• Row-level security (or Firebase rules) switched on for every table
• Policies written and tested for read, insert, update and delete
• Storage buckets private unless the files are meant to be public
• The app itself is not set to public when it should be internal

4. Input validation

Treat every form field, URL parameter and file upload as hostile.

• Inputs validated on the server, not only in the form
• Database queries use parameters or an ORM, never string concatenation
• File uploads limited by type and size
• User text that feeds an AI model is length-capped

5. Rate limiting, including anonymous users

This is where public AI features get expensive. OWASP lists unbounded consumption as a top risk for LLM apps, including "denial of wallet" attacks that run up pay-per-use costs, and recommends rate limits and user quotas.

• Limits per IP and per account on login, sign-up, password reset and AI endpoints
• Anonymous visitors get a small quota, or must sign in before using paid features
• A CAPTCHA or similar check on public forms that trigger email or AI calls
• No secrets in system prompts; OWASP warns that system prompts can leak and should not hold credentials or permission logic

6. Dependency audit

AI tools add packages freely, and sometimes suggest ones that are outdated or do not exist.

• Run npm audit, pip-audit or your stack's equivalent and fix high and critical issues
• Remove packages the app does not use
• Confirm every package name is the real, maintained one
• Turn on automated dependency alerts in your repository

7. Backups and recovery

• Automated daily database backups, kept somewhere other than the main account
• A restore tested at least once, with the time it took written down
• Uploaded files backed up, not just the database

A backup you have never restored is a guess.

8. Logging and monitoring

• Errors sent to a tracking tool such as Sentry
• Uptime check on the main pages and API
• Alerts for unusual AI or cloud spend
• Logs that record who did what, without storing passwords, tokens or full card or ID numbers

9. Error handling

• Users see a plain message, not a stack trace or database error
• Debug mode switched off in production
• Failed payments, AI timeouts and third-party outages handled without losing data

10. Ownership and handover

The most overlooked step. Many prototypes live in one person's personal accounts.

• Code in a company-owned repository, not a staff member's personal account
• Hosting, domain, database, email and AI provider accounts owned by the company, with at least two admins
• A short README covering how to run, deploy and roll back
• A named person responsible for updates, security patches and incidents

Quick score

Steps 1 to 3 are not optional. A single failure there outweighs passing everything else.

When to get a review or rescue

Self-checks catch the obvious problems. Bring in an outside reviewer when:

• The app holds personal, health or financial data, or will fall under India's DPDP Act or a client's security questionnaire
• It takes payments or calls paid AI models from a public page
• Nobody on the team can explain how login and permissions work in the code
• The person who built it is leaving, or the app has grown beyond what one person can maintain
• You have already seen strange sign-ups, spend spikes or data appearing where it should not

A review does not mean starting again. In most cases the prototype is a useful first draft, and hardening it is faster than a rebuild.

What a review and hardening engagement involves in India

Most published guides quote UK, EU or US agency rates, which can put a review out of reach for an Indian startup or SME. Here is what a typical engagement covers:

1. Access and inventory. Read access to the repository and hosting, and a list of every third-party service and key in use.
2. Review. Secrets scan, authorisation tests across user roles, database rule review, dependency audit and a check of rate limits and AI cost controls.
3. Findings report. Issues ranked by risk, each with a fix and an effort estimate.
4. Fixes. The critical items first, usually secrets, access rules and rate limits, then monitoring and backups.
5. Handover. Accounts moved to company ownership, a README, and an optional maintenance arrangement.

For a small app with a handful of screens and one database, the review itself is usually a few days of senior engineering time. Fixes depend on what turns up. We bill this kind of work against our hourly rate of ₹1,200–2,500, or through a monthly support and maintenance plan once the app is live; see pricing for current figures.

Where to go from here

If your app is close to launch, our quality assurance service covers security and functional testing before real users arrive. If the review shows the prototype needs deeper work, our web application team can harden it or rebuild the weak parts. To talk through your app, get in touch.

Still at the idea stage? Read how to plan your first AI project before writing any code.

Frequently asked questions

Is it safe to put a vibe-coded app into production?

It can be, once it has been checked. AI coding tools write working features quickly but often skip access rules, rate limits and secret handling unless asked. Run the checklist in this post, or have an engineer review it, before real customer data goes in.

What is the most common security problem in vibe-coded apps?

Data that anyone can read. It usually comes from a database without access rules, an API that checks whether a user is logged in but not whether the record belongs to them, or an app left public by default.

How do I stop people abusing the AI chatbot in my app?

Keep API keys and secrets out of the system prompt, require login or a per-visitor limit before the bot calls a paid model, cap message length, and set a hard monthly spending limit with your model provider.

How long does a security review of an AI-built app take?

For a small app with one database and a handful of screens, a focused review usually takes a few days of senior engineering time. Fixing what it finds depends on how many issues turn up, from a day to a few weeks.

Should I rebuild a vibe-coded app from scratch?

Usually not. Most prototypes can be hardened in place. A rebuild makes sense only when the data model is wrong for the product or the codebase is too tangled to change safely.