Skip to main content
Free self-assessment tool

Is Your AI-Built App Production-Ready? Free 18-Question Readiness Check

Answer 18 plain-English questions about your app, built with Lovable, Bolt, Replit, Cursor, v0 or similar. You get a readiness score for security, data, reliability, deployment and code ownership, plus a prioritised list of what to fix first. Nothing is sent anywhere unless you ask us to email the report.

What does production-ready mean for an AI-built app?

An AI-built app is production-ready when real users’ data is protected by rules the database enforces, secrets stay on the server, data can be restored after a mistake, failures alert someone, and changes are tested away from live users. Publishing the app proves none of these things.

Last checked: . Every check cites first-party documentation; sources accessed 15 October 2026.

Answer 18 questions about your app

Choose Not sure if you cannot check right now. Your answers stay in this browser.

0 of 18 answered
Which tool did you mainly build the app with? (optional, not scored)

Security & access

S1Is Row Level Security (or equivalent database access rules) turned on for every table, so each user can only see and change their own data?Critical check
How to check

In Supabase: Advisors → Security. No “RLS disabled” errors should show.

S2Are all secret keys (the Supabase secret or service_role key, the Stripe secret key, AI provider keys) kept only on the server and never in the code that runs in the browser?Critical check
How to check

Open your live site, view the page source or bundle (Ctrl+U), and search for service_role, sb_secret, sk_live or sk-.

S3Do sensitive actions (taking payments, changing roles, admin actions, sending emails, calling paid AI APIs) run on the server and check who the user is, instead of only being hidden in the interface?Critical check
How to check

Ask: “If someone called this action directly, without using our screens, would the server refuse?”

S4Are sign-up, login, password reset and any expensive endpoints (for example AI calls) protected against abuse with rate limits or CAPTCHA?
How to check

Check your Supabase Auth rate-limit and CAPTCHA settings, and whether your own API routes limit requests per user or IP.

S5Have you tested sign-up confirmation, login and password reset emails on your real domain, with the auth redirect URLs set to your production address?
How to check

Do a password reset from a private browser window on the live domain. The link should come back to your site, not to localhost or a preview URL.

Data & backups

D1Is your production database backed up automatically, and stored somewhere you can restore it from?Critical check
How to check

In Supabase: Database → Backups. On the Free plan, check whether anyone runs a regular export.

D2Has anyone actually restored a backup (for example into a test project) to prove it works?
How to check

Ask whoever manages the database for the date of the last test restore.

D3If users upload files (documents, photos, invoices), are those files private and protected by access rules, rather than in a public bucket?
How to check

In Supabase: Storage. Check whether each bucket is marked Public.

D4Do you know what personal data the app stores, and what you would do if it leaked, including reporting to the ICO when required?
How to check

Can you list the personal data fields you store and name who would decide whether to report a breach?

Reliability & monitoring

R1Do you get an automatic alert (email, Slack, SMS) when the app goes down or users hit errors, rather than hearing about it from users?
How to check

When did you last get an automated error alert? If never, the answer is probably No.

R2If you take payments, does the server verify that each Stripe webhook really came from Stripe, and safely ignore duplicates?Critical check
How to check

Ask your developer, or the AI tool, to show where the Stripe-Signature header is checked.

R3Is the live app on paid plans meant for production, with auth emails sent through your own email provider, rather than free tiers that can pause or limit emails?
How to check

Check your Supabase plan and whether custom SMTP is configured under Auth settings.

Deployment & environments

E1Do you have a separate test (staging or development) copy of the app, with its own database, where changes are tried before they reach real users?Critical check
How to check

Do edits in your builder’s preview touch the same database your users use? If yes, the answer is No.

E2If a release breaks something, can you roll back to the previous working version within minutes?
How to check

Do you know which button or command restores yesterday’s version, and has anyone tried it?

Code ownership & maintainability

C1Is the full source code in a GitHub (or similar) repository owned by your company account, so you could keep developing without the builder?
How to check

Can you open the repository on GitHub under your own organisation, not a contractor’s account?

C2Are the accounts the app depends on (domain, hosting, Supabase, Stripe, GitHub, AI provider) owned by the company, with at least two admins and multi-factor authentication turned on?
How to check

List each account and who can log in. If one person leaving would lock you out, the answer is No.

C3Are the critical user journeys (sign up, log in, pay, the core workflow) covered by automated tests that run before each release?
How to check

Is there a test command or CI check that fails if sign-up breaks?

C4Are you alerted when a package the app depends on has a known vulnerability, and were the packages the AI added checked to be genuine?
How to check

Check whether Dependabot (or npm audit in CI) is enabled on the repository.

0 of 18 answered

Your readiness score appears here.

Answer all 18 questions, then select See my readiness score. It updates if you change an answer.

0 of 18 answered

A self-assessment based on your answers, not a code audit. A high score does not prove your app is secure.

How the readiness score works

Each of the 18 checks has a weight. Weight 3 means the gap can cause a data leak, data loss or payment fraud on its own; weight 2 is a serious operational or security risk; weight 1 is good practice that reduces risk. The weights add up to 40 when every check applies.

Your overall score is the weighted share of credit you earn across all the checks that apply, from 0 to 100. It is weighted by check rather than averaged across categories, so security, which holds the most critical weight, moves the result most. Category scores use the same formula within each category.

Categories and maximum weights
CategoryChecksMax weight
Security & access513
Data & backups48
Reliability & monitoring37
Deployment & environments25
Code ownership & maintainability47
Credit for each answer
AnswerCreditMeaning
Yes1The safeguard is in place.
Not sure0.25Partial risk. An unverified safeguard cannot be relied on, so it earns a quarter of the credit. This is a deliberate choice in how the checker scores, not a statistic.
No0The safeguard is missing.
Doesn’t applyExcludedOnly for file uploads (D3) and payments (R2). The question is removed from the calculation entirely.

Bands and critical blockers

A critical blocker is any weight-3 check answered No (shown as Missing) or Not sure (shown as Unverified). With one or more blockers, the band can be no better than Needs hardening, whatever the score. Two or more weight-3 checks answered No make it High risk, whatever the score. These rules never change the number: you always see your real score, and the result explains when a rule changed the band.

Readiness bands
BandWhenWhat it recommends
ReadyScore 80 or more and no critical blockersFix the remaining items yourself. Re-run the check before adding payments, a larger user group or personal data. An assessment is optional, as a second pair of eyes.
Needs hardeningScore 50–79, or 80+ with at least one critical blockerFix the blockers before onboarding more users. Advisor findings, plan upgrades, MFA and backups have clear steps. For RLS policies, server-side logic and webhooks, get help if nobody on the team can confidently change the code.
High riskScore below 50, or two or more critical checks answered NoHold back on new sign-ups, payments or sensitive data until the critical items are fixed. Several foundations are missing at once and the order of fixes matters, so a fixed-scope assessment is the sensible next step.

The 18 checks, and why each one matters

These are the same questions and fixes the checker uses. Third-party figures are attributed to whoever reported them; they are not a measure of how often AI-built apps fail.

For the wider picture, see our guide to custom web application security. Database access rules are the same foundation we use for multi-tenant SaaS with Postgres RLS.

Security & access (max weight 13)
CheckWhy it mattersWhat to do if notSeveritySource
S1Database access rules (RLS)Is Row Level Security (or equivalent database access rules) turned on for every table, so each user can only see and change their own data?How to check: In Supabase: Advisors → Security. No “RLS disabled” errors should show.Supabase says a table in an exposed schema without RLS “is readable and writable by any role with a grant on it”. Escape reported missing RLS among the main issues in its October 2025 scan of vibe-coded apps.Turn on RLS for every table in the public schema. Write a policy for each operation (select, insert, update, delete) that checks the row belongs to the signed-in user. Then re-run the Supabase Security Advisor until no rls_disabled_in_public or permissive_rls_policy findings remain. Test by signing in as a second user and trying to read the first user’s data.Critical (weight 3)
S2Secret keys kept on the serverAre all secret keys (the Supabase secret or service_role key, the Stripe secret key, AI provider keys) kept only on the server and never in the code that runs in the browser?How to check: Open your live site, view the page source or bundle (Ctrl+U), and search for service_role, sb_secret, sk_live or sk-.Supabase says a secret key “bypasses every Row Level Security policy” and must never go in a browser. Stripe says secret keys “must stay in your server environment”. Escape reported finding over 400 exposed secrets in its October 2025 scan of more than 5,600 vibe-coded apps.Move every secret into server-side environment variables, and have your edge functions or API routes make the calls that need them. Then rotate every exposed key: Supabase says to fix the root cause of the leak first, then create and swap in the new key. Stripe says to rotate an exposed key “even if you aren’t sure anyone saw it”.Critical (weight 3)
S3Sensitive actions checked on the serverDo sensitive actions (taking payments, changing roles, admin actions, sending emails, calling paid AI APIs) run on the server and check who the user is, instead of only being hidden in the interface?How to check: Ask: “If someone called this action directly, without using our screens, would the server refuse?”Broken access control is A01 in the OWASP Top 10:2025, and OWASP’s validation guidance says “client-side validation is bypassable”. The Register reported (27 February 2026) a researcher’s claim that an inverted authentication check in a Lovable-hosted app let unauthenticated users in, exposing 18,697 user records.Move privileged logic into server-side functions or API routes that check the user’s session and role on every call. Validate all input again on the server. Remove any admin or debug routes that are publicly reachable.Critical (weight 3)
S4Abuse protection (rate limits, CAPTCHA)Are sign-up, login, password reset and any expensive endpoints (for example AI calls) protected against abuse with rate limits or CAPTCHA?How to check: Check your Supabase Auth rate-limit and CAPTCHA settings, and whether your own API routes limit requests per user or IP.OWASP says missing resource limits can lead to denial of service “but it can also lead to operational costs increase”, which matters when each request costs you AI credits. Supabase’s production checklist recommends CAPTCHA on sign-up, sign-in and password reset.Turn on CAPTCHA for Supabase Auth and review the Auth rate limits. Add per-user or per-IP rate limiting to your own API routes, starting with any that call a paid API. Set spending caps with your AI provider.Important (weight 2)
S5Auth emails and redirect URLsHave you tested sign-up confirmation, login and password reset emails on your real domain, with the auth redirect URLs set to your production address?How to check: Do a password reset from a private browser window on the live domain. The link should come back to your site, not to localhost or a preview URL.Supabase says the Site URL “is critical for email confirmations and password resets” and recommends exact redirect URLs in production rather than wildcards. Its production checklist also says to enable email confirmations.In Supabase Auth, set the Site URL to the production domain, restrict redirect URLs to exact production paths and enable email confirmations. Then test every auth flow end to end on the live domain.Important (weight 2)
Data & backups (max weight 8)
CheckWhy it mattersWhat to do if notSeveritySource
D1Automatic database backupsIs your production database backed up automatically, and stored somewhere you can restore it from?How to check: In Supabase: Database → Backups. On the Free plan, check whether anyone runs a regular export.Supabase backs up Pro, Team and Enterprise projects daily (Pro: the last 7 days) and recommends that Free-plan projects export regularly and keep off-site copies. During the July 2025 Replit incident, the agent reportedly told the founder no rollback was possible; heise later reported that a backup was in fact available.Move production to a plan with daily backups, or schedule automated supabase db dump exports to off-site storage. If losing even a day of data is unacceptable, add Point-in-Time Recovery, which Supabase recommends for databases above 4 GB.Critical (weight 3)
D2Tested backup restoreHas anyone actually restored a backup (for example into a test project) to prove it works?How to check: Ask whoever manages the database for the date of the last test restore.MIT’s production-readiness handbook requires “fully restorable backups for each non-ephemeral data store in production”. A backup that has never been restored is untested.Restore the latest backup into a separate project and check that the key tables and row counts match. Write down the steps and repeat them on a schedule, for example quarterly.Important (weight 2)
D3Private file storageIf users upload files (documents, photos, invoices), are those files private and protected by access rules, rather than in a public bucket?How to check: In Supabase: Storage. Check whether each bucket is marked Public.“Doesn’t apply” allowed.Supabase says public buckets “are already publicly accessible”; private access is controlled by RLS policies on storage.objects. Supabase also notes that database backups do not include objects stored through the Storage API.Make buckets that hold user files private. Add storage.objects policies that limit each user to their own folder, and serve files through signed URLs. Back up Storage separately.Important (weight 2)
D4Personal data inventory and breach planDo you know what personal data the app stores, and what you would do if it leaked, including reporting to the ICO when required?How to check: Can you list the personal data fields you store and name who would decide whether to report a breach?The ICO says a notifiable breach must be reported “without undue delay, but not later than 72 hours after becoming aware of it”. You can only meet that deadline if you know what data you hold.Write a one-page data inventory (what personal data, where it is stored, who can access it) and a short breach-response note: who decides, who contacts the ICO, who tells users.Good practice (weight 1)
Reliability & monitoring (max weight 7)
CheckWhy it mattersWhat to do if notSeveritySource
R1Error and uptime alertsDo you get an automatic alert (email, Slack, SMS) when the app goes down or users hit errors, rather than hearing about it from users?How to check: When did you last get an automated error alert? If never, the answer is probably No.OWASP Top 10:2025 lists Security Logging and Alerting Failures (A09) and says: “Without logging and monitoring, attacks and breaches cannot be detected.” MIT’s checklist requires application and availability monitoring in production.Add an error-monitoring tool to the front end and server functions, and an uptime check on the main URL and API. Send alerts to a channel someone watches.Important (weight 2)
R2Verified payment webhooksIf you take payments, does the server verify that each Stripe webhook really came from Stripe, and safely ignore duplicates?How to check: Ask your developer, or the AI tool, to show where the Stripe-Signature header is checked.“Doesn’t apply” allowed.Stripe warns that without verification “an attacker could send fake webhook events” to trigger actions such as fulfilling orders, and that endpoints “might occasionally receive the same event more than once”.Verify every webhook with the official Stripe library, using the raw request body and the whsec_ signing secret. Log processed event IDs and skip repeats. Return 2xx quickly and do the heavy work afterwards. Never let the browser mark a payment as paid; only the verified webhook should.Critical (weight 3)
R3Production plans and custom emailIs the live app on paid plans meant for production, with auth emails sent through your own email provider, rather than free tiers that can pause or limit emails?How to check: Check your Supabase plan and whether custom SMTP is configured under Auth settings.Supabase says it “may pause applications on the Free Plan that exhibit low activity in a 7-day period”. Its production checklist says the default auth email limit is 2 emails per hour unless you set up custom SMTP.Move the production database to a paid plan. Set up custom SMTP on your own domain for auth emails, with link tracking disabled. Review hosting and bandwidth limits for your expected launch traffic.Important (weight 2)
Deployment & environments (max weight 5)
CheckWhy it mattersWhat to do if notSeveritySource
E1Separate staging environmentDo you have a separate test (staging or development) copy of the app, with its own database, where changes are tried before they reach real users?How to check: Do edits in your builder’s preview touch the same database your users use? If yes, the answer is No.In July 2025 a Replit agent deleted a live production database during a founder’s test project; The Register reported that Replit’s CEO called it “unacceptable” and that Replit introduced separate development and production databases. The Twelve-Factor App advises keeping development, staging and production “as similar as possible”.Create a staging environment with its own database (a separate Supabase project or a branch) and matching configuration. Test schema changes and AI-generated edits there first. Give the AI tool no write access to production.Critical (weight 3)
E2Fast rollbackIf a release breaks something, can you roll back to the previous working version within minutes?How to check: Do you know which button or command restores yesterday’s version, and has anyone tried it?MIT’s production-readiness handbook requires a documented release process. With code in Git, every change has history that can be reverted; Bolt’s docs describe GitHub as backing up work “with a full history of changes”.Deploy from a Git repository, not straight from the builder. Use a host that keeps previous deployments, and write down the rollback steps. Pair this with staging so risky database migrations are rehearsed first.Important (weight 2)
Code ownership & maintainability (max weight 7)
CheckWhy it mattersWhat to do if notSeveritySource
C1Code in your own GitHubIs the full source code in a GitHub (or similar) repository owned by your company account, so you could keep developing without the builder?How to check: Can you open the repository on GitHub under your own organisation, not a contractor’s account?Lovable says project code is “stored and managed inside the Lovable platform” by default and that connecting GitHub gives you your own copy. Bolt and v0 document similar GitHub integrations. Without one, the app depends on the builder subscription.Connect the builder’s GitHub integration to a repository in your own organisation. Confirm it is private and contains everything: front end, database migrations and server functions. Check that a developer can run it outside the builder.Important (weight 2)
C2Company-owned accounts with MFAAre the accounts the app depends on (domain, hosting, Supabase, Stripe, GitHub, AI provider) owned by the company, with at least two admins and multi-factor authentication turned on?How to check: List each account and who can log in. If one person leaving would lock you out, the answer is No.Supabase’s production checklist says to protect your account with MFA, consider enforcing MFA across the organisation, and add more than one owner so access survives if one owner is unavailable.Move every account to a company-owned login or organisation, add a second admin and turn on MFA everywhere. Keep a private register of which account owns what.Important (weight 2)
C3Automated tests on critical journeysAre the critical user journeys (sign up, log in, pay, the core workflow) covered by automated tests that run before each release?How to check: Is there a test command or CI check that fails if sign-up breaks?MIT’s handbook asks for “continuous integration builds which run the full test suite”. Without tests, each AI-generated change can silently break something else.Start with end-to-end tests for the three to five journeys that make or lose money. Run them automatically on every change before deploy, then grow the suite as features change.Important (weight 2)
C4Dependency vulnerability alertsAre you alerted when a package the app depends on has a known vulnerability, and were the packages the AI added checked to be genuine?How to check: Check whether Dependabot (or npm audit in CI) is enabled on the repository.OWASP Top 10:2025 lists Software Supply Chain Failures as A03. GitHub says Dependabot alerts “notify you about vulnerable dependencies”.Turn on Dependabot alerts and security updates, and run npm audit in CI. Check every unfamiliar package the AI added against the official registry before installing it, and remove unused ones.Good practice (weight 1)

What has gone wrong in real AI-built apps

Reported incidents, attributed to the people who reported them.

  1. Production database deleted by an AI agent (July 2025)

    During SaaStr founder Jason Lemkin’s test project, a Replit agent deleted the live database despite instructions not to make changes. The Register reported that Replit’s CEO called it “unacceptable” and that the company introduced separate development and production databases.

    Source: The Register, 22 July 2025

  2. Platform-level authentication bypass (July 2025)

    Wiz Research reported a flaw in the Base44 platform that let anyone with a public app ID create verified accounts on private apps. Wiz reported that the flaw was fixed in under 24 hours.

    Source: Wiz Research, 29 July 2025

  3. Exposed secrets at scale (October 2025)

    Security vendor Escape reported analysing over 5,600 publicly available vibe-coded apps, finding more than 2,000 vulnerabilities, over 400 exposed secrets and 175 instances of personal data. Escape reported exposed Supabase keys and missing RLS among the main issues.

    Source: Escape, 29 October 2025

  4. Inverted access check in a single app (February 2026)

    A researcher told The Register that a Lovable-hosted education app exposed 18,697 user records because its authentication logic blocked logged-in users and let anonymous ones in. Lovable said the app included code it did not generate and a database it did not host.

    Source: The Register, 27 February 2026

These are reported incidents, not a measure of how often AI-built apps fail. They show which checks matter.

Where Lovable, Bolt, Replit and v0 leave you

Built only from each vendor’s own documentation, accessed 15 October 2026. It covers only tools whose documentation we checked. Whatever the tool, the checks above still apply to your app.

What each AI app builder documents, and what is still on you
ToolGetting the code into your own GitHubBuilt-in safety features (per vendor docs)Still on you
LovableGitHub integration with two-way sync. By default, code is “stored and managed inside the Lovable platform”. (Lovable GitHub docs)Quick scan on publish (database rules, npm dependencies); optional Deep scan. (Lovable security docs)Lovable says its tools “cannot guarantee complete security” and recommends a professional review for sensitive apps. Backups, staging, monitoring and account ownership.
Bolt.newGitHub integration; repositories start private. (Bolt Git docs)Bolt Cloud hosting on .bolt.host; custom domains on Pro. (Bolt Cloud docs)Database rules, secrets, backups and staging.
ReplitNot covered in the Replit documentation cited here.Separate development and production databases; the Agent cannot modify the production database. Published security checklist covering HTTPS, secrets, rate limiting and npm audit. (Replit databases docs; Replit security checklist)Applying that checklist to your own app, plus backups, monitoring and account ownership.
v0GitHub integration; publishing opens a pull request. (v0 GitHub docs)Deploys via Vercel projects. (v0 GitHub docs)Database rules, secrets, backups and monitoring.

Fix it yourself, or get an assessment?

Ready: work through any remaining items yourself and re-run the check before you add payments, a larger user group or more personal data. An independent review of the code is optional, as a second pair of eyes.

Needs hardening: many fixes have clear steps you can follow yourself: Security Advisor findings, plan upgrades, MFA and backups. Database access policies, moving logic to the server and payment webhooks are harder to change safely. If nobody on your team can confidently change that code, that is where an assessment fits.

High risk: several foundations are missing at once, and the order of fixes matters. For example, turning on Row Level Security can stop screens working that relied on open access, so changes should be tested on a staging copy first. Our vibe-coded app rescue starts with a fixed-scope assessment, quoted after a short call, that recommends whether to rescue, refactor or rebuild.

If a rebuild is recommended, estimate a budget with the UK MVP cost calculator and see how we approach MVP development. If your app adds AI features that handle customer data, our secure AI development service covers the extra controls those need.

Production readiness FAQs

How do I know if my Lovable app is production-ready?

Check five things: database access rules (Supabase Row Level Security) are on for every table; secret keys are only on the server; you have backups you have tested restoring; someone is alerted when the app fails; and changes are tested away from live users before release. The same applies to apps built with Bolt, Replit, Cursor or v0. The checker above walks through 18 such checks and ranks what to fix first.

Is Lovable's built-in security scan enough?

It is a useful first step, but Lovable's own documentation says its security tools “cannot guarantee complete security”. It also recommends a professional security review for apps that handle sensitive data or critical functions. The scan also does not cover backups, staging environments, monitoring or who owns your accounts.

What is Supabase Row Level Security and why does it matter?

Row Level Security (RLS) is a set of database rules that decide which rows each user can read or change. Supabase's documentation says to “enable RLS on every table in an exposed schema”. It also warns that such a table without RLS “is readable and writable by any role with a grant on it”.

Is it safe that my Supabase key is visible in the browser?

It depends which key is visible. The publishable (formerly “anon”) key is designed to be public, but it “only reaches what Row Level Security allows”, so it is only safe if RLS is on. The secret (formerly “service_role”) key “bypasses every Row Level Security policy”. Never put it in a browser. If it has been exposed, fix the cause of the leak first, then rotate the key.

Does Supabase back up my database automatically?

On paid plans, yes. Supabase says it backs up Pro, Team and Enterprise projects daily, and Pro projects can access the last 7 days. It advises Free-plan projects to export their own data regularly with the CLI and keep off-site copies. Database backups do not include files stored through Supabase Storage.

Why does “Not sure” lower my score?

A safeguard you have not checked cannot be relied on. “Not sure” scores as partial risk: a quarter of the credit of “Yes”. On a critical check it also counts as a blocker, because the cost of being wrong is a data leak. Finding out is usually quick, and the fix list tells you how.

Does the checker look at my code or collect my answers?

No. It is a self-assessment that runs in your browser and does not connect to your app or repository. Your answers are only sent to us if you choose to have the report emailed. In that case they are handled as described in our privacy policy.

My score is low. Do I need to rebuild the app?

Not usually. Most of the checks are fixed by configuration and targeted code changes, not a rewrite. A rebuild makes sense when the data model or architecture cannot support what the product now needs. Our fixed-scope assessment, quoted after a short call, recommends one of three routes (rescue, refactor or rebuild) and explains why. If a rebuild is recommended, our free UK MVP cost calculator gives an indicative budget.

Sources

All accessed 15 October 2026.

  1. Supabase: Row Level Security, accessed 15 October 2026
  2. Supabase: API keys, accessed 15 October 2026
  3. Supabase: Production checklist, accessed 15 October 2026
  4. Supabase: Database backups, accessed 15 October 2026
  5. Supabase: Database advisors, accessed 15 October 2026
  6. Supabase: Storage access control, accessed 15 October 2026
  7. Supabase: Auth redirect URLs, accessed 15 October 2026
  8. Stripe: Webhooks, accessed 15 October 2026
  9. Stripe: Secret API key best practices, accessed 15 October 2026
  10. OWASP Top 10:2025, accessed 15 October 2026
  11. OWASP Top 10:2025 A09 Security Logging and Alerting Failures, accessed 15 October 2026
  12. OWASP API Security Top 10 2023: API4 Unrestricted Resource Consumption, accessed 15 October 2026
  13. OWASP Input Validation Cheat Sheet, accessed 15 October 2026
  14. ICO: Personal data breaches, a guide, accessed 15 October 2026
  15. GitHub: About Dependabot alerts, accessed 15 October 2026
  16. GitHub: About secret scanning, accessed 15 October 2026
  17. The Twelve-Factor App: Dev/prod parity, accessed 15 October 2026
  18. MIT Open Learning Engineering Handbook: Production ready, accessed 15 October 2026
  19. Lovable: Security, accessed 15 October 2026
  20. Lovable: GitHub integration, accessed 15 October 2026
  21. Bolt: Git integration, accessed 15 October 2026
  22. Bolt: Bolt Cloud, accessed 15 October 2026
  23. Replit: Development and production databases, accessed 15 October 2026
  24. Replit: Vibe code security checklist, accessed 15 October 2026
  25. v0: GitHub, accessed 15 October 2026
  26. The Register, 27 Feb 2026: Lovable-hosted app exposed 18K users, researcher claims, accessed 15 October 2026
  27. The Register, 22 Jul 2025: Replit response to the SaaStr database deletion, accessed 15 October 2026
  28. heise online: Replit production database deletion, accessed 15 October 2026
  29. Escape, 29 Oct 2025: vibe-coded app vulnerability research methodology, accessed 15 October 2026
  30. Wiz Research, 29 Jul 2025: Base44 critical vulnerability, accessed 15 October 2026

Want someone to check the code, not just the answers?

Our assessment reviews the code, database policies, secrets, integrations and deployment set-up of your AI-built app. It is a fixed-scope assessment, quoted after a short call.

Book a short call Vibe-coded app rescue