Need Help Fixing or Securing
Your Vibe-Coded App?
A quick AI-built prototype can prove the idea before the underlying software is ready for company use. We review the code, access controls, data model and operational gaps before customers or staff depend on it.
98%
IN ONE SCAN HAD A FLAW
172
ALLOWED UNAUTHENTICATED DELETE
48h
TO STOP THE BLEEDING
AI-built apps often hide backend problems
AI coding tools are excellent at the bit users see. Buttons, layouts, copy, animations. The back half is also vibe-codeable, but without someone who knows what good looks like, it goes live with the boundaries missing and shortcuts everywhere.
Auth, permissions, payments, data integrity, secrets, rate limits. Then the next layer: error handling that swallows things, queries that don't scale, features the AI half-finished, costs nobody's watching. The app runs, and "runs" looks identical to "safe and ready to grow" until it isn't.
If your app handles money, accounts, files, or anything a customer would notice when it broke, you want a human eye on the back half.
WHAT THE AI GAVE YOU
- Public database with one anon key
- API keys in the JavaScript bundle
- Admin pages "hidden" by a route
- Errors swallowed, users see blank pages
- Slow queries, no caching, no indexes
- Half-finished features nobody flagged
WHAT IT NEEDS
- Row-level rules per user, per table
- Secrets on the server, rotated
- Role checks enforced server-side
- Errors caught, logged and paged
- Queries that scale past 100 users
- The half-built features finished
What we check first
Public scans of Lovable, Bolt.new, Replit, v0 and other Supabase-backed apps keep turning up the same failures. Performance, reliability and the half-finished features come right after.
Open database
Supabase Row Level Security off, or a single policy reading true. Anyone with the public key reads, edits and deletes every row.
Secrets in the bundle
Stripe, OpenAI and service-role keys embedded in JavaScript anyone can view-source. One copied key can spend money or access data outside the app.
Auth in the browser
Admin checks done in client-side React. Change one variable in dev tools and you're staff. Endpoints never verify "is this your record".
Payments on trust
Stripe and PayPal webhooks with no signature check. Anyone can POST "they paid" and the app believes them. Refunds, never reconciled.
No limits, no eyes
No rate limits on login, password reset or the LLM endpoint. One script can burn through API spend, and without logs you won't know which route did it.
How we take it into live use
Triage first, then fix, then improve. First pass is 24 to 48 hours: leaked keys, exposed data, broken auth, missing webhook checks. Then we rebuild the parts that need a real developer and finish the bits the AI half-built.
You keep the app you built. We keep the AI editor working alongside us, so you can carry on building after we leave.
BOOK A TRIAGE CALLTriage (24 to 48 hours)
With read access to the repository and services, we document immediate exposure, incomplete engineering, operational gaps and the work needed before the software supports company use.
Stop the bleeding
We contain immediate exposure first, then repair authentication, permissions, webhooks, server-side controls, rate limits and error reporting in an agreed order.
Rebuild and finish what matters
Auth, payments, file storage, the LLM endpoint, the slow queries, the half-built features, the error paths the AI never wrote. Rewritten properly, tested, deployed somewhere you can monitor. The UI stays. The rest gets a backbone.
Hand back something you can grow
Backups running, alerts wired to your phone, an audit log you can search, a written list of what's safe to keep vibe-coding and what isn't. Optional retainer if you want us building the next set of features alongside you.
Published failures in AI-built apps
These public incidents show the production risks that can remain after a generated application looks complete in a demonstration.
170 Lovable apps, one scan.
Researcher Matt Palmer scanned 1,645 Lovable projects and found 303 vulnerable endpoints across 170 projects, about 10.3% of the sample. MITRE scored CVE-2025-48757 at CVSS 9.3; NVD lists it as disputed.
Public projects exposed build history.
Lovable said public project chat history and source code could be accessed by any Lovable user with a project link between 3 February 2026 and 20 April 2026. The company also said related reports were closed without escalation.
18,697 user records.
The Register reported Taimur Khan found 16 vulnerabilities, six critical, in a Lovable-hosted education app with more than 100,000 views. The exposure covered 18,697 user records, including 4,538 student accounts.
Sources: NVD, Matt Palmer, Lovable, The Register, Symbiotic Security, OWASP, Supabase, Stripe and PayPal.
We review the system behind the interface
Our public review of a Lovable-built marketing product covers the issues that appear after the demo works: AI cost exposure, data persistence, authentication, validation and a dependable route to production.
When this is worth discussing
We work best when there is a real operating problem, enough volume to measure and people from the affected teams who can make decisions.
Usually a good fit
- An established UK business, usually with annual revenue above £10m
- A repeated process with a known cost, delay, error rate or capacity problem
- A senior sponsor and a day-to-day owner who understand the work
- Access to the relevant staff, systems, sample records and security requirements
We may point you elsewhere
- A standard product already covers the process well
- The requirement is a one-off small build with no wider operating case
- There is no owner or access to the people and data needed to test the result
- The plan relies on AI making high-impact decisions with nobody responsible for review
Questions before connecting the systems
Do I have to throw the whole thing away?
Almost never. The UI is usually fine, often genuinely good. It's the back half that needs rewriting. We keep what works, replace what doesn't, and you carry on building.
Can I keep using Lovable / Bolt / Replit after?
Yes. We leave the editor in place for the parts it's good at: layouts, marketing pages, copy changes, new screens. We give you a written list of which parts are safe to vibe-code and which need a developer.
How fast can you start?
A live customer or security incident is triaged before planned improvement work. We agree the containment priority, access and decision-maker first, then scope any stabilisation or rebuild from the evidence.
What do you need from me?
We need read access to the repository, hosting, database and relevant third-party services, plus a business owner who can explain the intended behaviour and approve priorities. We agree a safe test route before changing any live system.
Can you fix slow, buggy or unfinished features too?
Same engagement. Triage flags it, the rebuild fixes it. Slow queries get indexed or rewritten, errors get caught and logged, the half-finished feature gets finished. Security comes first because the cost of getting it wrong is highest, but we don't leave the rest broken.
How much does it cost?
Triage is fixed-fee. Stop-the-bleeding sprint is priced per finding. Full rebuilds are scoped against the report, fixed price per phase. We tell you the number before we touch a line of code.
What if I've already been hit?
For a live incident, the first job is containment: revoke exposed access, preserve evidence and establish what may have been affected. Your legal, privacy and communications owners remain responsible for notification decisions while we investigate and fix the technical cause.
Talk to us about the app
Send us the URL, repository and intended users. We will define the immediate risks, the work needed for dependable use and whether repair or replacement is the better investment.