For businesses
Vibe coding for business: what to check before you hire
A checklist before you hire someone to build your site or app with AI: who owns the code and accounts, backups, keys, testing, and what if they vanish.
Today anyone can build a website or an app with AI over a weekend, and that's a good thing. The trouble starts when the weekend version begins to store bookings, payments and details of real clients. In October 2026 the Israeli business site Bizportal ran a piece under the headline (in Hebrew) "5,000 apps without adequate protection: the business risk of vibe coding". I build with AI every day, and that's why I think it's worth knowing what to ask before you hire someone who builds this way. Even if it's me.
Is vibe coding safe for a business?
It depends less on the tool and more on who checks what the tool wrote. A 2025 Veracode study tested more than a hundred language models on 80 coding tasks and found that in about 45 percent of cases the generated code introduced a security flaw. Their July 2026 report paints a similar picture: the models got better at writing code, but not at writing safe code.
There are real cases too. In 2025 a flaw (CVE-2025-48757) was published in apps built with Lovable, one of the popular tools for building with AI: missing permission settings in the database let strangers read and change data. Lovable disputed the report and said protecting the data is each customer's responsibility. For a business owner that is exactly the point: if nobody is responsible, you are.
Will you see something working before you pay?
This question filters out a lot. Someone who builds with AI can show a working version quickly, so there's no reason to pay for a spec document before you've seen a single screen. With me the first version costs nothing, and we talk about payment only after you've seen it and decided to go on. Even if you choose someone else, ask to see something working early. It shows you how they work, not just what they promise.
Who owns the code and the accounts?
You do. And it's worth having that in writing, not just said. The code should live in a repository registered to you, and the accounts the system runs on should be yours: the domain, the hosting, the database, the email provider and every paid service. If the domain is registered to the builder and they stop answering the phone two years from now, you have a problem no code will fix.
When I built a room booking system for the Shiluv clinic, it ran on the clinic's accounts from the start: the servers, the database and the calendars. I built it, they own it, and I hand over the source code and access whenever they want. There's no lock-in to me.
Where are the passwords and keys kept?
Not inside the code, and not in a WhatsApp message. Access keys for services like the database or the payment provider belong in the place the hosting provider set aside for them, and they should be replaceable. Ask the builder what happens if a key leaks: who replaces it, and how fast. Ask too what of theirs stays on your computers. My rule is that nothing stays: not my account and not my files.
What happens to the data if something breaks?
In the summer of 2025 a Replit AI agent deleted a production database, in the middle of a period when it had been told explicitly not to change anything. Replit responded by promising to separate the development and production environments automatically. The lesson for a business is simple: a system with real data needs a backup that sits outside the system, and a separate test environment where every change is tried before it reaches clients.
Shiluv has a nightly backup to the clinic's own storage, and every change is tested first on dummy data and only then reaches real renters. If your builder can't tell you where the backup is and when someone last checked that it can be restored, you don't have a backup. You have hope.
How do you know the builder checks what the AI wrote?
You ask. Are there automated tests? Who reads the code before it goes live? What happens when a test fails? Someone who works seriously answers that easily and in detail. The Shiluv system has 54 test files today.
And if the system itself has AI that takes actions, ask what it may do on its own. At Shiluv the clinic's Claude can prepare an action such as a booking or a cancellation, but every such action waits for a person's explicit approval before it happens.
What if the builder disappears?
Plan for it from day one. A good handover includes the source code, every account in your name, and documentation that tells whoever comes next what the system does and why it's built that way. Another developer should be able to pick up from the same point without guessing. Ask to see the documentation before the end, not only at handover.
A short checklist
Before you sign, get a clear answer to each of these:
- Did I see a working version before I committed to pay?
- Is the code in a repository registered to me, or will I get it whenever I want?
- Are the domain, hosting, database and email provider registered to me?
- Are the keys and passwords kept outside the code, and can they be replaced?
- Is there a backup outside the system, and has someone checked it can be restored?
- Is there a test environment separate from the system my clients use?
- Are there automated tests, and does someone read the code before it goes live?
- If the system has AI, does it need a person's approval before any action that changes something?
- Is there documentation another developer can pick up from?
- Do I know what it costs to run the system each month, and whose name the accounts are in? (I wrote about that in what decides the cost of building a site or app with AI.)