Case · Vibe code check
Assess first, then go live. That is the smart way.
A consultancy built its own AI-readiness assessment in Lovable and wanted it inside their WordPress site. Instead of launching it right away, they had it assessed first. Wise: no malicious code, but five points that had to be fixed before going live.
If the review turns up no improvements, we credit it.
Leon Katz · CIO
This check was carried out by Leon Katz.
The situation: one HTML file, with everything in it
The client delivered a standalone HTML file: an interactive multi-step questionnaire the visitor completes in the browser, with a lead form (name, business email, role, industry). Answers, scores and lead data go straight from the browser to an external cloud database; benchmark figures come back from that same database.
It works, it looks good, everyone is excited. Then the real question: can this go live safely, on a site where customers leave their data?
What we found
Five points before going live
Public key in the code
The database access key sits in the source. Whether submitted names and email addresses can be read by third parties then depends entirely on the permissions on the database side. One wrong setting and everything is exposed.
Personal data to a cloud service
Personal data is processed at an external party: that falls under the GDPR. Processor agreement, privacy statement and EU hosting location were not yet arranged.
Unlimited submissions
Any browser may submit without limit. Automated abuse pollutes the database and the benchmark figures, and costs money when the service bills per request.
Dependent on an external CDN
A script is loaded from a third party on every visit: a dependency, and every visitor's IP address travels along.
Fifth point: the styling in the file clashes with the WordPress theme. Pasting it straight into an HTML block causes style and script conflicts, so the integration had to be isolated.
The advice
From finding to concrete measure
- 01
Lock down permissions
The anonymous role may only insert, never read; read access only on a view without personal data. Actively tested, not assumed. Plus a request limit per key as a safety net.
- 02
GDPR in order
Processor agreement with the database provider, mention in the privacy statement, hosting within the EU, and a privacy notice at the form.
- 03
Slow down abuse
Rate limiting, a honeypot field and a captcha where needed; host the script locally instead of via the CDN.
- 04
Integrate in isolation
As a static file outside the WordPress content, loaded via an iframe with tight sandbox rights. No conflicts with theme or plugins, and an update means replacing one file.
Checklist
What had to be ticked off before going live
- Database permissions verified and tested: the anonymous role cannot read personal data.
- API request limit set; a test submission arrives correctly.
- Processor agreement signed, hosting location checked, privacy statement extended.
- External library hosted locally; honeypot and rate limiting in place.
- Iframe tested on desktop and mobile, including height behaviour and failure scenarios (blocked scripts, unreachable database).
- One source location and one contact person for updates agreed.
What the check deliberately is not: a legal verdict on the app itself. The workings of the application and the configuration of the database stay with the client; we assess, advise and integrate.
That it works proves the idea is right. Whether it can go live safely is a second question, and this client asked it themselves, before any customers went in. That is the credit this case deserves: not that there were points (there always are), but that they were found before they mattered.
Assess first, then go live. That is the smart way.
Read on
The routes behind this case
Vibe code check
The check for apps built with AI tools.
From POC to production
Your first working version ready for real users.
Integration in website/CMS
AI connected to the system you already know.
Built something with AI too?
If the review turns up no improvements, we credit it.