Over a single weekend you built a client portal, an intake tool or an internal app with Claude or Cursor. It runs, it looks good and your team is already using it. It feels like the best investment of the year, and it may well be. But an app that works is not yet an app that is safe, and precisely in that gap sit the vibe coding risks that can cost a business thousands.
We are in favour of vibe coding ourselves. We build with AI every day and we see how fast it takes you from idea to working product. What we also see: code written by AI and reviewed by AI usually looks fine. Only later, once real users and real data are in it, do the holes surface. In this article you will read which risks are the largest, why AI misses them itself, and how we catch them before anything goes live.
The five biggest vibe coding risks
Most of the warnings you see online come from the United States. The mechanisms are the same here, the rules simply go by different names. These are the five risks we run into most often.
1. A simple website with an uncapped bill
A static site on a platform like Netlify or Vercel normally costs you nothing. Until someone floods it with fake traffic. In 2024 a developer received a bill of $104,500 for a simple hobby site after a DDoS attack. Netlify only waived it once the story went viral on Hacker News. Many of these platforms charge per gigabyte and have no hard ceiling by default. An AI assistant that deploys your site will not set that limit for you.
2. A database that is open to everyone
Tools like Lovable and Bolt build on Supabase by default. There, row level security (RLS) decides who may see which data. Switch it off and anyone with the public key from your JavaScript can read your entire customer table. In 2025 a researcher scanned more than 1,600 apps from Lovable's showcase and found critical leaks in 170 of them, more than 10 percent. For a European business that is a data breach under the GDPR, with a duty to report it to the regulator within 72 hours.
3. API keys in your code and functions that call themselves
AI likes to put keys for OpenAI, Stripe or your mail provider straight into the code, because then it works right away. Once deployed they sit there in the open. A second classic is a function that keeps calling itself. In 2020 a startup burned $72,000 on Google Cloud in a few hours during a test. Budget alerts did not help: they send an email, they do not stop anything.
4. A site that is not accessible
The European Accessibility Act has applied since 28 June 2025. Online shops, online banking services and other digital services for consumers must be accessible: operable by keyboard, images with alt text, sufficient contrast. Micro-enterprises providing services are exempt, but anyone larger running an AI-built site without checks is taking a real risk. AI delivers visually attractive interfaces, but accessibility is rarely included as standard.
5. Unsolicited messages to your waiting list
You launch, so you email or text everyone who ever signed up. Under European rules you need prior consent for commercial electronic messages, and the GDPR requires you to be able to prove that consent. Regulators do enforce this. A form that AI builds in an hour usually does not record that consent properly.
Why AI does not see its own holes
The logical response is: then I will have AI review my code. We do that too, and it helps. But it is not enough. Our experience is that an AI review often concludes everything is in order, while you discover holes step by step as you keep building. A missing permission check here, a key that made it into a build after all there.
That happens because a language model optimises for code that works, not for code that holds up against someone trying to abuse it. It tests the path you describe, not the path an attacker picks. We see this same pattern with clients who come to us with a self-built or cheaply built app. We do not share details, because we work under NDA there. The pattern is always the same: the product does what it is supposed to do, and so nobody looks further.
How we catch vibe coding risks
We build with AI ourselves, only with a fixed review process around it. That is the difference between a prototype and a product you can hand to customers with confidence.
Two AIs checking each other. We have two leading models review the same code independently and pit them against each other to find holes. What one model misses, the other often catches. After that a developer goes through the findings, because the final word stays human.
A fixed checklist before going live. Every delivery goes through the same list: permissions per database table, keys, rate limits, accessibility and consent. That is dull work, and exactly why we do not do it on instinct.
Self-hosted Supabase. We run Supabase on our own servers. We set up row level security per table, and your customer data stays within the EU. That fits how we also work with European language models on our own infrastructure.
No keys in the code and every API monitored. API keys get an expiry date and never end up in a deploy. We track the usage of every API, so that a function running wild stands out before the bill arrives, not after.
Accessible from the first version. We build to the requirements of the European Accessibility Act, and clients now actively ask about it.
Build it yourself or have it built?
Vibe coding is an excellent way to test an idea, make an internal tool or show what you mean. As long as there is no customer data, no payments and no public access involved, the risk is limited. As soon as one of those three enters the picture, have a developer look over it before you go live.
Want it properly sorted from the start? Then we will build it for you. We use AI too, because it makes you fast, but with the checks AI itself skips. From AI implementation and automation to custom web apps and websites. Already built something and want to know where it stands? Book a call and we will look at it together.
