Vibe coding for companies: safely from AI prototype to business app

"Vibe coding" means describing to an AI in plain language what an application should do, and letting it write the code. Tools like Lovable, v0, Bolt, or Claude Code deliver something clickable within hours. According to an analysis of Google search data, no country searches for the term more per capita than Switzerland.

For companies, this is more than a trend. For the first time, the people who know a process best can build the tool for it themselves: the dispatcher her planning tool, the sales manager his quote calculator, the quality lead her inspection reports. No requirements document, no "that's not what we meant," no months of waiting.

That's a good development. We believe software fits best when it's built close to the business. The only question is what happens after the first working screen.

An AI prototype shows that an idea works. It doesn't show that it works securely, reliably, and maintainably. The AI builds what you describe. What you don't describe is usually missing: a proper permissions concept, protected credentials, backups, updates, logs, a plan for when something goes wrong.

The numbers are clear. In a study of 1,645 Lovable apps, 170 had not protected their database against outside access; names, email addresses, and API keys were exposed. In February 2026, a single Lovable app came to light with 16 security vulnerabilities that exposed the data of more than 18,000 people. And according to Veracode's 2026 report, AI-generated code passes a security check only 56 percent of the time on average — barely better than the year before.

None of this argues against AI tools. It argues against filling an unreviewed prototype with real customer and business data. The platforms say so themselves: whoever builds the app is responsible for its security.

First: who may see what? Every business app needs roles and permissions enforced on the server — not just in the browser. A login screen alone doesn't protect any data.

Second: where do the application and its data run? On the platform where the prototype was built, or with a hosting partner you chose yourself and whose account you have access to?

Third: what happens when something goes wrong? Are there daily backups, and has anyone ever tried restoring from them? Is there a test environment where changes are checked before they go live?

Fourth: who keeps the application up to date? Every app relies on dozens of third-party components, and security updates for them come out all the time. Without someone installing them, a secure app becomes insecure over time.

Fifth: who will understand the code a year from now? If the person who built it with the AI leaves the company or runs out of time, someone else has to be able to take over. That requires a clear structure, a code repository with history, and reviews that share the knowledge.

Many companies first ask whether the AI sees their data during development. Done properly, it doesn't: building and testing happen with test and sample data, and the development environment has no access to the live system. Real customer and business data never comes up while building.

For data protection law, two other questions are decisive. Where does the live system run, and where are the data and backups stored? And does the finished application use AI itself, for example to summarize documents or classify requests? Then real data flows there, and it matters where that model runs. Both have good answers in Switzerland and the EU today: hosting partners with data centers here, and capable AI models that run in Switzerland or the EU.

What matters is that someone answers these questions for every component and writes them down — before the app goes live, not after. A blanket "compliant" label on a platform is no substitute.

The first way: the prototype serves as a reference, and a development partner rebuilds the application properly. That's right when the application becomes business-critical and complex, or when nobody in-house has time to keep building. The prototype isn't lost then — it's the best specification there is.

The second way: the prototype gets hardened. An experienced person reviews architecture, security, and data protection, closes the gaps, moves the code into your own repository, and brings the application onto infrastructure you own. That pays off when the basic structure holds.

The third way: your experts keep building — but with guardrails. They develop in a shared environment, every change is reviewed before it goes live, and someone takes care of servers, updates, backups, and monitoring. That keeps the speed and the expertise in-house, and the result still holds up.

Which way fits depends less on technology than on how much your people want to shape things themselves.

For the third way, we built the ZNIPP Workbench. Your experts build with Claude Code in a browser-based development environment, and we work in the same project. Every change lands in your private GitLab; we review it for architecture, security, and data protection; you accept it in the test environment and approve it for live.

The live system runs on your own account with a Swiss or European hosting partner, such as Hosttech, Infomaniak, or Hetzner. We don't host ourselves; we maintain the application servers, install updates, back up daily, and keep an eye on monitoring. Code, data, and access belong to you — from day one.

And if a prototype already exists, we start with a Workbench Check: we tell you honestly whether it can be hardened or whether a rebuild is the better way.