Vibe code audit
Lovable gets you a working app fast, usually React on the front, Supabase for data and Stripe for payments. Before real users and real money arrive, we check what was generated for your product: who can see which records, whether payments survive retries, and where your keys live.
Lovable can produce a working app on a solid stack. Whether your app is safe depends on what was generated for your product: the database policies, the payment flow, the keys and the tests. Those decisions live inside your project, and they need a review by someone who reads code before real users and money arrive.
The questions below apply to any app on the same building blocks, whichever tool wrote it. They are the questions a payment provider, a partner or an investor will ask sooner or later.
We check the four places where apps on React, Supabase and Stripe most often break after launch: database and file access rules, the payment flow under retries and parallel requests, keys and secrets, and the release process. Each area is scored, and every finding comes with a fix ranked by priority.
Row-level security policies tested as real users from different accounts, and Storage file access compared with the privacy of each record. Row-level security is the set of database rules that decides which rows each user may read.
Supabase security auditWebhooks that verify signatures and apply events in order, customer and checkout creation that cannot run twice, collections that are safe to retry.
API keys and the Supabase service role key kept on the server, out of the app bundle and out of git history.
Tests on sign-in and payment flows, a type check and a release gate, so a new prompt cannot quietly break what already works.
We have audited apps built on the same pieces Lovable uses. A Supabase app had hardcoded API keys live in production and payment endpoints with no authentication. A Stripe app had webhooks that were stubs, so payments never worked. In a third audit, two first-time requests created two payment customers.
Hardcoded API keys live in production. Payment endpoints with no authentication.
Zero tests, and pushes went straight to production. The readiness score was 3 out of 10. Keys were revoked and both critical holes patched within 48 hours.
See all audit casesStripe webhooks were stubs. Payments never worked.
An open redirect in the sign-in flow, and CI never ran the 16 test files. Nobody knew payments were dead. We stopped the launch, and the app launched 6 weeks later.
Two first-time requests created two payment customers.
In the same audit an older webhook overwrote a newer plan state, and a retried job could collect the same share twice. The fix is idempotent customer creation and collection, so a repeated request returns the first result. From our anonymised sample report.
Sample report based on a real audit. Client details and figures changed.
Connect the GitHub repository with read-only access, or tick that you have a Lovable project with no GitHub and we arrange access by email. A senior engineer reviews the code across 8 areas. You get a readiness score, ranked findings with fixes, a fixed-price cleanup quote and a debrief call.
Read-only access to GitHub, GitLab or Bitbucket, or to the Lovable project itself. Revoke it any time.
Code, database policies, payments, keys and release process, scored across 8 areas.
A business summary for you and a technical report your next developer can work from.
A call with the engineer who wrote the report. Bring a partner or a technical friend.
The vibe code audit starts from $199 at a fixed price. After the audit you get a fixed-price quote for the cleanup, agreed before any work starts, and you decide whether to take it. If you keep building with Lovable after the fix, a fractional CTO can stay on retainer.
It can be the start of one. Lovable builds on common pieces: React, Supabase and Stripe. A production app also needs tested access rules, payments that survive retries, keys kept on the server and a release process. Those depend on your project, so check them before you take payments or personal data.
The risks we look for sit in the generated project: database policies that let one user read another user’s records, files readable through Storage, keys in client code, payment webhooks that do not verify or repeat safely, and no tests guarding any of it.
Yes. The audit ends with that answer and the reasons for it. We say rebuild only when the data model cannot carry the product, and we show why. All 4 codebases on our audit page were fixable without a rebuild. Most fixes were local changes, scoped in a fixed-price quote.
No. GitHub, GitLab and Bitbucket all work with read-only access, and so does a Lovable project with no repository at all. Tick the box for a Lovable project with no GitHub when you apply, and we arrange access by email. You can revoke access at any time.
Book a 30-minute call. Tell us what the app does and when you plan to take payments, and we will tell you what the audit covers.
Prefer to talk?
