Taking Vibe-Coded Apps to Production: The Security and DevOps Check for AI-Built Software

One of our new clients is a managing director in the holiday-rental industry. No developers in-house, no tech team. And yet he runs an intranet with shift planning, leave management and an internal wiki, plus several dashboards that pull data from more than 20 sources. All self-built, with Claude, Supabase and Vercel. Honestly: we’ve seen projects from actual teams that were less well thought out.

And then came the moment he stopped himself. Before roughly 30 employees got access, he wanted someone who does this every day to check it: does everyone really only see their own data? Can someone from outside get in who has no business being there? Do roles and permissions rest on a clean concept – or on a few lines that happen to work?

That exact moment is the subject of this article. Because “vibe coding” – building software by AI prompt instead of line by line – gets tech- and AI-savvy people impressively far today. The limit is almost always in the same place: the step into production. Security, roles and permissions, deployment, back-ups, DevOps. This article shows, with evidence, why that step is the critical one, which vulnerabilities we find most often, and what a clean path from a self-built app to a production system looks like.

Vibe coding gets further than most people think

Up front, so this doesn’t turn into a cheap “AI code is garbage” piece: what non-developers build today with tools like Claude, Cursor, Lovable or v0 is impressive. Working intranets, internal tools, prototypes that model real processes – in weeks instead of months. This isn’t a toy, it runs in daily operations. We’ve described elsewhere how non-developers now build production software with AI and why that’s a genuine shift.

The problem isn’t that these apps get built. The problem is the quiet transition from “works on my machine” to “30 people rely on it and it holds personal data.” That’s exactly where AI-generated code behaves differently than it feels.

Where it breaks: the numbers on AI-generated code

AI optimizes for “it works,” not for “it’s secure.” And working code that is insecure looks just as finished as secure code. That’s the most dangerous kind of flaw: the one you can’t see at first glance.

The evidence is now unambiguous:

• The 2025 GenAI Code Security Report by Veracode tested 80 coding tasks across more than 100 language models. Result: 45% of the generated code contained an OWASP Top 10 vulnerability. For cross-site scripting the failure rate was 86%, for Java over 70%. In this study, AI code contained 2.74x more vulnerabilities than human-written code.
• A study by Carnegie Mellon University found that while 61% of AI code is functionally correct, only 10.5% passes a security review.
• According to a SonarSource developer survey, 53% of developers who shipped AI code later discovered security issues in production – not in review, but in live operation.

These aren’t numbers from the AI-sceptic camp; they come from application-security vendors and universities. And they describe code written by professionals using AI. In vibe coding without a security background, the decisive step often drops out entirely: security requirements are never even stated.

The classic: the database whose doors were never locked

By far the most common pattern we see in AI- and no-code-built apps involves the database. Modern stacks like Supabase make getting started easy: create a table, query it directly from the frontend, done. What gets overlooked is Row Level Security (RLS) – the rule that defines who may read and write which row. Without active RLS policies, a table reachable from the browser is reachable by anyone.

How real this is shown by CVE-2025-48757: in May 2025, security researcher Matt Palmer found, in apps built with Lovable, 303 endpoints across 170 projects whose database tables could be read without any login, using only the public anon key. Email addresses, phone numbers, payment data and API keys were exposed. And it’s not a one-off: analyses around these incidents attribute 83% of Supabase data leaks to RLS misconfiguration. An Escape.tech analysis of 5,600 applications found over 2,000 exploitable vulnerabilities, including 400+ exposed secrets and 175 cases of exposed personal data.

The core of the problem is always the same: a database that works because its access rules were never switched on.

The six vulnerabilities we find most often

Beyond the database, the same patterns repeat in AI-built applications. These six are what we check first:

The tricky part: each of these gaps can be avoided with one or two sentences in the prompt – “no secrets in code, all keys from environment variables; on every route, check whether the logged-in user may access exactly this data.” You just have to know it. Someone who has never secured an application in production doesn’t phrase those sentences – and the AI usually doesn’t suggest them on its own.

The DACH factor: GDPR turns a bug into a reportable event

In Germany, Austria and Switzerland an open database has a second dimension. As soon as personal data – employees, customers, guests – can be accessed without authorization, that’s not just a technical flaw but potentially a reportable personal-data breach under Article 33 GDPR, to be reported within 72 hours. Fines run up to €20 million or 4% of global annual turnover.

On top of that come the questions that tend to slip through in AI- or no-code-built apps: where are the servers? Is there a data processing agreement (DPA) with the platform provider? Can access and deletion requests actually be fulfilled technically? None of this is a reason not to build with AI – but a strong argument for having someone who knows this chain look at it before rollout. How we think about data protection and architecture together is also covered in our piece on AI readiness in the enterprise.

From app to production system: the DevOps craft

Security is one half. The other is ongoing operation. Because after rollout the application isn’t finished – it starts to live. New features, new interfaces, schema changes. Push all of that straight to the main environment and you have a problem, especially with the database. “Claude, be careful” is not a strategy for a production system 50 people use daily.

The good news: the software world solved this long ago. DevOps as a discipline has existed since 2009, and the principles are independent of whether a human or an AI writes the code. What’s standard for us when an MVP becomes a production system:

• Branches and worktrees – the baseline even vibe coders manage.
• CI/CD: changes are built and tested automatically before they go live.
• Separate environments: staging first, filled with a current dump from production, then production.
• Automatic DB backups before every major deployment, so rollbacks take minutes instead of hours.
• Clean architecture from day 1, API-first, clearly separated domains.
• Logs and monitoring that someone actually watches.
• Deploy small pieces instead of the big all-in feature: one change at a time, deploy, test, move on. If something breaks, the damage is small and the rollback so fast that no one notices in live operation.

On tests, use judgement: a thousand unit tests for every trifle add little, end-to-end tests before rollout add a lot – and then click through it yourself, because you only see edge cases there. One thing AI development tends to forget: maintain the CLAUDE.md or AGENTS.md, record learnings and post-mortems. Then the project doesn’t make the same mistake twice. This approach is part of what we understand as forward deployed engineering: close to the client’s codebase, with the craft that keeps a system running six months from now too.

How production-ready is your application?

Before you decide whether your self-built application is ready for rollout, take the quick self-check. It doesn’t replace an audit, but it gives you an honest sense of where you stand:

Where the line runs – and why it’s no contradiction

Nothing in this article argues against vibe coding. On the contrary: if you’re tech- and AI-savvy, you should build. The client from the opening did exactly the right thing – he recognized the point himself instead of going live, hoping, and only calling when things caught fire. The real competence isn’t “being able to do everything yourself,” it’s knowing where your own competence ends.

Roughly speaking, the line runs where a personal tool becomes a system with multiple users, real data and responsibility. From there it pays to bring someone in – for a one-off security and production check, or to accompany the step into stable operation.

That’s exactly what we do at TAISC: we review AI-built applications for database access, login, roles and permissions and the critical interfaces, and we accompany the path from MVP to a production-ready system with security, DevOps and clean architecture. Not to replace what was self-built, but to make it hold up.

FAQ

FAQ

Is AI- or no-code-built software inherently insecure?

No. What is insecure is not the method but the missing step: with vibe coding, security requirements are often never stated. Studies show around 45% of AI-generated code contains an OWASP Top 10 vulnerability – but with the right instructions and a review before rollout, that can be fixed deliberately.

What is the most common security gap in AI-built apps?

An open database from missing Row Level Security (RLS). If the table is reachable from the browser but has no active access rule, practically anyone can read it. In the Lovable incident (CVE-2025-48757) data from over 170 projects was readable without a login, and around 83% of Supabase data leaks trace back to RLS errors.

How do I know my application needs a professional check?

As soon as several people access it, it processes personal data, or the app becomes business-critical. At that point at the latest, roles and permissions, database access, secrets handling and DevOps basics matter – so exactly before rolling out to a whole team.

Do I have to throw away my AI-built app and rebuild it?

Very rarely. Usually it is about securing and productionizing what exists: adding RLS and authorization, separating secrets cleanly, setting up staging and backup processes. That is far cheaper than a rebuild and preserves the work already in there.

What does a security and production check at TAISC cost?

It depends on the size of the application and how critical it is. In a free intro call we look at the concrete state and tell you which points are mandatory before a rollout and which can come later.

Conclusion

Vibe coding has shifted the question. It’s no longer “can I build this myself?” but “is what I built ready for real users and real data?” The numbers are clear: AI code is functionally strong but unreliable on security, and the most common gap – the open database – quickly costs more than nerves in the DACH region. The way forward isn’t to build less with AI, but to take the last step deliberately: security, roles and permissions, DevOps.

Built something yourself and want to know if it survives the move into production? Book a no-obligation intro call – we’ll look at it together, before 30 people get access.