You Vibe-Coded an App. Now What?

A risk-first security checklist for 1–5 person startups: what to fix today for free, what can wait, and what to check before you call it "production-ready."

You built it in a weekend with Lovable, Bolt, v0, Replit, Cursor or Claude Code. Now real people are signing up. You don't have a dedicated engineer, your budget is close to zero, and one question keeps coming back:

Is this thing actually safe to run?

Founders usually come to us asking about scale: will it handle 10,000 users? For a team of one to five people, that's almost never the right first question. The honest answer is usually closer to this:

"Whether your vibe-coded app will scale isn't your problem yet. Your problem is the Supabase key sitting in the browser bundle."

So this checklist goes in the order that matters for a tiny team. Security exposure and data loss come first. Then knowing when the app is down, then having a codebase someone else can pick up. Scalability and investor readiness come last, once you have real traction.

Why vibe-coded apps carry hidden risk

A vibe-coded app is software you built mostly by describing what you wanted to an AI coding tool and accepting what it generated, without a developer reviewing every line. Andrej Karpathy coined the term in early 2025, and the practice has gone mainstream since.

Mostly, that's a good thing. Founders who could never afford an engineering team can now test ideas in days.

The risk usually isn't the quality of any one feature. It's what's missing around the features, the operational and security layer a senior engineer adds out of habit:

• Database rules that stop one user from reading another user's data
• Secrets kept on the server, out of the browser and out of git history
• Backups that have actually been restored at least once
• Alerts that fire before a customer emails support
• Someone, anyone, who can explain how the app works

AI tools optimize for "it works." Nobody asked them to optimize for "it's safe to run in production."

The incidents are rarely dramatic. They tend to be mundane, cheap to prevent and expensive to clean up. The extreme case: in July 2025, an AI coding agent deleted a live production database during an explicit code freeze on a high-profile founder's project. Backups are the one control that turns an event like that from company-ending into an annoying afternoon.

6 things to fix today, for free

Do these before you spend any money. Together they take an afternoon, and they remove most of the "bad week" scenarios for a small team.

1. Rotate any API key or credential that might be exposed. If a key has ever been in client-side code, a public repo or an AI chat log, treat it as burned. It takes about 30 minutes if you know where to look.

2. Turn on your host's one-click backups. Supabase, Railway, Render, Neon and most other platforms have backups built in, often free or a few dollars a month. If you've never checked, assume they're off.

3. Set up a free uptime monitor. The free tier of UptimeRobot or Better Stack tells you the app is down before a user does.

4. Add a free error tracker. Sentry's free tier catches the bugs that would otherwise pile up unnoticed.

5. Turn on 2FA everywhere. That means hosting, your domain registrar, your payment processor, GitHub, and any other account that could sink the company if someone took it over.

6. Publish a basic privacy policy and terms of service. Free templates exist. Don't skip this even before revenue if you collect any user data at all.

The 8 risks, in priority order

Not every risk deserves your attention today. We rank them by likelihood × impact for a 1–5 person team, and by whether you can realistically fix them yourself.

1. Exposed secrets and broken authentication

High likelihood × high impact.

API keys, database credentials or admin routes end up in client-side code, git history or default platform settings. This is the number-one way vibe-coded apps get hacked. It's also how founders end up with a surprise five-figure bill because someone else is using their OpenAI or cloud key.

Why AI tools cause it: if you ask an assistant to "make the feature work," it will happily put a key where the browser can read it, or leave row-level security off because the demo works without it.

What you can do: rotate every key you suspect, move secrets to server-side environment variables, and check that your database denies access by default.

What's hard to do alone: knowing you found everything. Exposures hide in old commits, forgotten preview deployments and unprotected API routes.

2. No backups

Medium-high likelihood × catastrophic impact. This is the one mistake you can't undo.

One bad migration, a dropped table or a bug that overwrites data, and there's nothing to restore from. Turning backups on is easy. Knowing they actually restore is harder. A backup you've never tested is a hope, not a plan. Do one test restore into a separate project and time how long it takes.

3. No monitoring

High likelihood × medium impact.

The app goes down, a third-party API starts failing or a bug ships, and the founder finds out hours later from a support email. This is the easiest risk on the list to fix yourself: an uptime monitor plus an error tracker covers about 80% of it. The alerts do need to reach a phone someone actually looks at.

4. A fragile, undocumented codebase

Medium impact. It blocks hiring, fundraising and handoffs.

The AI wrote the code, and nobody, including the founder, can confidently explain how half of it works. The knowledge lives in old chat histories, and every fix gets riskier over time. It's rarely urgent on day one, but it gets in the way of every next step: hiring your first engineer, raising a round or handing the product to an agency.

5. Cost and performance landmines

Low likelihood now, rising fast as you grow.

Inefficient queries, no caching, or a generous free tier that turns into a real bill the moment usage grows tenfold. AI-generated code often fetches a whole table when it needs one row, or calls a paid API inside a loop. Check for this before any launch, PR push or paid campaign.

6. Data privacy and compliance blind spots

Depends on your situation. It can be high, and get high fast.

This means collecting emails, payment details or other personal data with no privacy policy, no consent flow and no basic sense of what GDPR or CCPA requires. For a generic SaaS, a template covers most of it. In health or fintech, or with EU users, the impact climbs very quickly. This is where we most often see founders underestimate their exposure.

7. Scalability architecture

Low likelihood before traction.

The app is built the way vibe-coding tools default to, not the way it would need to work at 100 times today's traffic. Our advice: don't pay to solve a problem you don't have yet. Come back to it when traffic or infrastructure costs climb month over month.

8. Investor and acquisition readiness

Depends on your situation. It only matters when you're raising, and then it matters fast.

A term sheet or acquisition conversation suddenly needs technical answers nobody prepared: your security posture, the architecture, who owns the code, how data is handled. You can't pull technical due diligence together in the week before it starts. Build it before the ask, not during it.

What to do in your situation

Find the line that sounds most like you:

• Non-technical founder, MVP built with Lovable, v0 or Replit, real users now: run the free self-check above, then get an independent risk scan before you tell anyone it's "production-ready."
• Technical co-founder who leaned hard on Cursor or Claude Code and isn't sure what's in the codebase anymore: write handoff documentation and turn the knowledge in your chat history into something the team can rely on.
• A user reported a bug that looks like it exposed someone else's data: a scan won't cover this. You need emergency stabilization, today.
• About to process real payments for the first time: lock down secrets and auth first, then do a privacy and compliance check.
• About to raise a pre-seed or seed round: run a risk scan now so diligence holds no surprises.
• About to hire your first engineer: document the codebase first. The new hire's first week will go very differently.
• Usage just jumped after a launch, a PR mention or a viral post: check your queries and costs before the next invoice arrives.
• Something broke in production and nobody knows why: get help. The point is not having to figure it out alone.

The rule of thumb

If the fix is a toggle, do it yourself. If the problem is "I don't know what I don't know," get help.

Backups, uptime monitoring, error tracking and 2FA are toggles. Finding every exposed secret across your git history, preview deployments and API routes is not. Neither is telling an investor with confidence that your app is secure.

Get the full checklist

We've turned this into a free Excel playbook with the full risk matrix and decision table. Download the vibe-coded app checklist

Gart Solutions helps small, AI-built products become safe to run, with work scoped in days, not months. That ranges from a one-day Vibe Code Risk Scan, which gives you an evidence-based answer to "how much risk is hiding in here?", to focused sprints on secrets and auth, backups and monitoring.

If you want to know exactly what's exposed and what to fix first, book a Risk Scan.