Let's talk

SELF-CHECK · AI-BUILT APPS

Vibe coding risk check for AI-built apps

The vibe coding risk check is a 10-question self-check that shows where an app built with AI tools is most likely to break: security, data, payments or operations.

Start the checkProduction down? Get help
Led by Thanos GkanasCo-Founder, engineering

The drawing shows an AI-built app as ten checkpoints and, under it, the browser calling the database with a public key, so its row rules are the only gate.

It is an AI-built app risk check for founders who shipped fast with an AI app builder or coding assistant. Run it once real users, real data or real money move through the product. Not sure is a valid answer. The result gives your risk level, what to fix first and what to check next, so you know where AI-generated code risk sits in your app.

Your answers stay in this browser. Nothing you choose is stored or sent.

  1. 01Does every page and API route that shows private data check that the visitor is signed in?

    Check the API requests behind each screen, not only the page.

    More

    AI builders often protect the page and leave the request behind it open.

    On the map: sign-in

    Why it matters: If an API route answers without a sign-in check, anyone can read the data by calling it directly.

  2. 02Does your database return only the rows that belong to the signed-in user?

    This is row-level security, or an equivalent ownership check in every query.

    On the map: db rules

    Why it matters: Without row-level rules, one user can often read or change another user’s records by changing an ID in a request.

  3. 03Are all secret keys, such as database service keys and payment or email API keys, kept on the server and out of the code sent to browsers?

    Service, admin and secret keys must stay on the server.

    More

    Public keys meant for the browser are fine.

    On the map: secrets

    Why it matters: A secret key in browser code can be copied by anyone who opens the developer tools, and it often unlocks everything.

  4. 04Does your server confirm each payment with the payment provider, for example through a signed webhook, before it unlocks anything?

    Choose “No payments yet” if the app does not take money.

    On the map: webhooks

    Why it matters: If the browser tells your app that a payment went through, a visitor can fake that message and get paid features without paying.

  5. 05Do you have automatic database backups, and have you restored one at least once?

    On the map: backups

    Why it matters: A backup you have never restored is a guess. One bad change or deleted table can lose your customers’ data.

  6. 06Do automated tests run on sign-in, payments and your core feature before each release?

    On the map: tests

    Why it matters: Without tests, each AI-generated change can quietly break a flow that worked yesterday.

  7. 07Would you hear about errors in production from your own logs or alerts before a customer tells you?

    On the map: alerts

    Why it matters: Without error logging and alerts, failures stay invisible until customers complain or leave.

  8. 08Do you update your app’s packages and check them for known security issues on a regular schedule?

    On the map: packages

    Why it matters: Old packages collect published vulnerabilities, and attackers scan for them automatically.

  9. 09Do changes go to a separate staging or preview environment before they reach real users?

    On the map: staging

    Why it matters: Changing the live app directly means every experiment runs on real customers and real data.

  10. 10Is the code in a repository your company owns, with access you control?

    On the map: repo

    Why it matters: If the code lives only in a builder account or a freelancer’s repository, you may not be able to move, audit or sell it.

0 OF 10 · 0 TO FIXSee result

Your result

Your result appears here when all 10 questions have an answer.

How the result works

Each answer adds to a score. A No on any of these puts the result in the high band on its own: sign-in on private pages and APIs, access rules in the database, secret keys kept on the server, payments confirmed on the server. Any other No, and any Not sure, puts it in the medium band or above.

LOWER RISK
Your answers show no clear gaps in the basics this check covers. It cannot see your code, so treat it as a starting point: a review before a launch or a funding round is still worth it.
MEDIUM RISK
Your answers show gaps or open questions worth closing before you add users or raise money. Work through the list below from the top: each item is a common way AI-built apps break or leak data.
HIGH RISK
Your answers point to a gap that can expose data or money, or to several basics that are missing or unknown. Deal with the first items below before you add features or users.
Led by Thanos GkanasCo-Founder, engineering

A high score is a list of places to look, not a verdict. Bring your Fix first list to a 20-minute call and we will go through it with you. Already broken in production? Go straight to software project rescue.

Book a 20-minute call (opens Google Calendar in a new tab)

AI code audit and fix

STEP BY STEP

How the vibe coding risk check works

Each question covers one part of your app that AI tools often get wrong or leave out. Four are about security and money: sign-in, who can read which rows, where your secret keys live and how payments are confirmed. The other six cover backups, tests, error alerts, package updates, a separate test environment and who owns the code.

  1. Pick the answer closest to the truth for each question. Not knowing is a real answer: it usually means nobody has checked.
  2. As you answer, a map of your app marks the part each question covers. It shows a tick when it looks fine, a flag to fix, a question mark to check or a dash when it does not apply.
  3. When you finish, the result shows your overall risk level, the gaps to fix first and the answers to check next. Any Not sure answer puts the result at medium risk or above, because a part nobody has checked may be a gap. Each comes with a concrete step, and the parts that look fine are listed too.

Your answers stay in your browser. Nothing you choose is sent to BrainStormers or stored anywhere, and there is no sign-up. If website analytics is on, the page counts one event when a result is shown, without any of your answers. The whole check takes a few minutes.

Found problems you cannot check yourself? Our AI code audit and fix for vibe-coded apps reads the code, confirms what is real and fixes it in order of risk.

METHOD

Where the questions come from

Thanos Gkanas, our Head of Engineering, wrote the questions. They follow the failure modes that public security guidance warns about and that AI-built apps tend to share. These include missing access rules, secrets shipped to the browser, payments never verified on the server, permissions nobody has tested and no way back from a bad deploy.

The sources behind the questions, such as the OWASP Top 10, are listed with the check, each with the date it was last checked. The weights are a judgment call, not a statistical model: they point to where to look first, and a low score does not prove your app is safe.

If you are still asking "Is vibe coding bad?" at all, our guide covers what tends to break when AI code ships. For the 2026 incidents that show what is at stake, read Vibe coding security: why AI-built apps exposed data in 2026.

Sources checked

  1. OWASP Top 10owasp.orgCHECKED 11 OCT 2026
  2. PostgreSQL documentation: row security policiespostgresql.orgCHECKED 11 OCT 2026
  3. OWASP Secrets Management Cheat Sheetcheatsheetseries.owasp.orgCHECKED 11 OCT 2026
  4. Stripe documentation: receive events in your webhook endpointdocs.stripe.comCHECKED 11 OCT 2026
  5. NIST SP 800-218, Secure Software Development Frameworkcsrc.nist.govCHECKED 11 OCT 2026

FAQ

Questions about the vibe coding risk check

What does the vibe coding risk check measure?

It measures how exposed your AI-built app is, not how good the code looks. The 10 questions cover access to data, keys and secrets, payments, backups, tests, error alerts, package updates, a separate test environment and who owns the code. The result shows your overall risk level, what to fix first and what to check next.

Are my answers stored or sent anywhere?

No. The check runs in your browser, and your answers never leave it. Nothing you choose is stored or sent to BrainStormers, and there is no sign-up. If website analytics is on, the page counts a single event when a result appears, without any of your answers, so we can see whether the tool is used.

Does the risk check replace a code audit?

No. The check works from what you know about your app, and a code audit works from the code itself. The check helps you decide where to look and whether an audit is worth it. Only someone reading the code, the database rules and the configuration can confirm a risk or rule it out.

Which AI app builders does the check apply to?

All of them. The questions are about your app, not the tool that wrote it, so they apply whether you used Lovable, Bolt, Replit, Cursor, Claude or a mix. They also apply to apps built quickly by hand: missing access rules and exposed keys are not unique to AI-generated code.

What should I do with a high-risk result?

Start with the area the result flags first and check it before you add features or users. Often that means confirming who can read and change each table, moving secrets off the client and verifying payments on the server. If you cannot check those yourself, ask an engineer who did not build the app to review the code.

NEXT STEP

Want the code checked?

The check tells you where to look. If you want someone to look for you, tell us what you built, which tool you used and what the result flagged.

You’ll talk to Thanos

Book a 20-minute call (opens Google Calendar in a new tab)Tell us about your project (opens our project form in a new tab)