¶ Service · Production readiness review
Is your AI-built app ready for real users?
A written, severity-ranked review of your app before customer data and payments flow through it. You learn what must be fixed before launch, what can wait, and what is already fine.
Lovable · Bolt · v0 · Cursor · Claude Code
Who it is for
Founders and product owners who built an app with an AI builder or a coding agent and are about to open it to paying customers, a pilot client or an investor’s technical team. It is just as useful for an internal tool that suddenly handles customer or financial data.
- LovableReact front end on a Supabase backend: access rules, auth settings and edge functions
- BoltFull-stack apps in the browser, often with Supabase or Netlify: keys, environments, hosting
- v0Next.js apps on Vercel: server actions, API routes, environment variables
- CursorAny stack your team or a freelancer chose: structure, tests, dependencies
- Claude CodeAgent-written repositories: consistency, permissions, CI and what the agent was allowed to do
Severity-ranked · read top to bottom
What we check
The checklist below is the backbone of every review. Each item carries the default severity it gets when it fails. The actual rank depends on your app and the data it holds.
- SEV-1
Data access
Row level security is enabled on every table, and policies match who may read and write which rows
supabase/migrations/*
- SEV-1
Secrets
No service-role key, payment secret or private API key reaches the browser bundle or the repository history
dist/assets/*.js · .env*
- SEV-1
Authentication
Every server route and function checks who is calling, not only whether someone is signed in
api/* · functions/*
- SEV-1
Payments
Payment webhooks are verified, idempotent and the single source of truth for what a customer has paid for
webhooks/stripe.*
- SEV-2
Dependencies
Every package exists, is maintained, is the one you meant to install and has no known critical vulnerability
package.json · lockfile
- SEV-2
Input handling
User input is validated on the server; queries, file uploads and redirects cannot be abused
forms · uploads · queries
- SEV-2
Deployment
Separate environments, repeatable database migrations, backups that have been restored at least once
ci/* · infra
- SEV-2
Privacy
Personal data flows are known, processors are listed, logs do not collect more than needed (technical view, not legal advice)
logs · analytics · emails
- SEV-3
Tests
Sign-up, payment and the core workflow have automated tests that run before each deployment
tests/* · ci/*
- SEV-3
Architecture
Business logic lives in one place and the code can be changed by a developer who did not write it
src/*
- SEV-3
Running costs
No polling loops, unbounded queries or model calls that grow faster than your user count
hosting · database · LLM usage
- SEV-3
Operations
Errors are logged and someone is alerted when sign-up, payment or email delivery fails
monitoring
A written findings report
What you receive
A written findings report with clear priorities, in English, that you can share with your co-founder, your developers or an investor. Its length depends on what we find, not on a template.
- Summary for decision-makers
- One page in plain language: can this go live, and what has to happen first.
- Findings, ranked by severity
- Each finding names the location (file, table, setting), explains the risk in one paragraph and recommends a fix.
- Severity scale
- SEV-1: fix before launch. SEV-2: fix soon after launch or before you scale. SEV-3: plan it into normal development.
- Relative effort
- Each fix is marked small, medium or large, so you can plan it with your developers.
- What is fine
- We also list what is in good shape, so nobody rewrites code that does not need it.
- Next steps
- Options to fix it yourself, with your developers, or with us. You choose; the report stands on its own.
From public research and vendor documentation
Common risk categories in AI-built apps
These categories are documented in public security research and in the vendors' own documentation. They are not findings from our reviews; they are what a review checks for first.
-
Database access rules that are missing or too open
Apps built on Supabase talk to the database directly from the browser. That is safe only when row level security is enabled and the policies are correct. A public vulnerability record documents insufficient row level security policies in apps generated by Lovable, which allowed unauthenticated reading and writing of database tables.
Source: NVD: CVE-2025-48757 · Supabase docs: Row Level Security
-
Secret keys in the client
Supabase separates a publishable key, which may be public, from secret and service-role keys, which bypass access rules and must stay on the server. Any key that ends up in the browser bundle or in a public repository should be treated as compromised and rotated.
Source: Supabase docs: Understanding API keys · GitHub docs: About secret scanning
-
Broken access control
Broken access control is the first entry of the OWASP Top 10. In generated code it can look correct: the page hides a button, but the API behind it accepts any request. A review checks the server side, where the rule has to live.
Source: OWASP Top 10
-
Packages that should not exist
Research on code generated by large language models found that models recommend package names that do not exist. An attacker can register such a name and wait for someone to install it. A dependency review checks that every package is the real one.
Source: Spracklen et al., "We Have a Package for You!" (arXiv)
-
Payment events that are not verified
Stripe documents that webhook endpoints should verify signatures and handle duplicate events. If an app trusts the redirect after checkout instead of the verified webhook, customers can get access without paying, or pay without getting access.
Source: Stripe docs: Webhooks
-
LLM features that trust their input
If your app itself calls a language model, prompt injection and excessive agency become application risks. OWASP maintains a separate Top 10 for LLM applications that a review uses as a checklist.
Questions
Do you need access to our code?
Yes. A production-readiness review reads the repository, the database configuration and the deployment setup. Read-only access is enough. If your app still lives only inside Lovable or Bolt, we help you export it to a GitHub repository you own first.
Is this a penetration test?
No. It is a code and configuration review: we read how the app is built and where it is exposed. If the findings show that a dedicated penetration test makes sense, for example before an enterprise customer signs, we say so in the report.
Can you fix the findings as well?
Yes, if you want that. The report is written so that your own developers or a freelancer can work from it. You decide after reading it who does the work.
I am not technical. Will I understand the report?
The summary is written for decision-makers, without jargon. The detailed findings are written for whoever fixes them. In the intro call we also talk about who on your side will read which part.
Does the review cover GDPR?
It covers the technical side: which personal data your app stores, where it goes and which services process it. It is not legal advice. For legal questions you need a lawyer or a data protection officer, and the report gives them a clear technical picture to start from.
Our app is built with something other than Lovable or Bolt. Is that a problem?
No. The checks apply to any web application. What matters is that the code was written fast, with a lot of AI help, and now has to carry real users and real data.
¶ Intro call
Book a free intro call
30 minutes, free of charge. Tell us about your app or your team, and we will tell you honestly whether and how we can help. We reply within one business day.
- You describe the app or the team setup.
- We ask about the stack, the data and what is at stake.
- You get an honest view of whether a review, a rescue or a rollout makes sense.