A website from Lovable, v0 or ChatGPT with no developer - 5 risks nobody tells you about

You typed two sentences about your company into Lovable or ChatGPT and fifteen minutes later you had a website. It looked good. The form worked. And then came the question the tutorials do not answer: can this be my company website? The one I put on my business card, the one I hook appointment bookings up to, the one nobody has to look at for a year.

A disclaimer up front, as in every post in this series: I make a living building websites, so I have an interest in you commissioning one after all. At the same time AI is a permanent part of my toolkit - I work with Claude Code and Copilot every day, which I wrote about in the pros and cons of an AI-generated website. So I have no reason to scare you off the tool. I do have a reason to tell you where the prototype ends and responsibility begins - and, honestly, when vibe coding is perfectly enough.

The short answer (for the impatient)

Vibe coding, meaning generating a website as code in Lovable, v0, Bolt or ChatGPT, is a great way to build a prototype, an internal tool or a test of an idea. And a risky way to build a company website that collects customer data, needs to rank in Google and needs to still work a year from now. The line is not in the tool. It is in the question: who is answerable for this site when it stops working, or when the form leaks.

The term itself is young - it dates to February 2025, when Andrej Karpathy described building programs by describing them in words without reading the code that comes out. That last part is the crux. AI code can be good. The problem is that nobody reads it.

What vibe coding actually is - and how it differs from Wix and from WordPress

Three different things get mixed together in conversations about "an AI website", and which one you have decides how much of this post applies to you.

A builder on a subscription (Wix, Framer, Squarespace). The platform holds the site, you pay monthly, you do not have the code. But somebody - the platform - is answerable for the server staying up and the form not leaking. I compared builders with WordPress in Wix vs WordPress.

Vibe coding (Lovable, v0, Bolt, ChatGPT plus hosting). AI writes real code, usually in React or Next.js, sometimes with a Supabase database behind it. That code is formally yours. And nobody except you is answerable for it. This is the key difference and the spine of this whole post.

WordPress from a developer. The code and the data are yours, and a specific human with a contract is answerable for them working. What that costs and what you are paying for is in how much a WordPress website costs.

One distinction that lowers the temperature of this post for most readers. In practice, most "AI websites" a small company runs into are static HTML: a few pages, photos, copy, one form. No database, no logins. A site like that has nothing to "leak" beyond that form, and its real risks are the scripts the generated code drags in, maintenance and SEO. A full Lovable application - database, user accounts, bookings with payments - is all five risks at once. Check which one you have before reading on.

What you actually get after an hour of prompting

You get a working interface and often a working database. That is true and it is impressive - I am not going to pretend otherwise.

You also get things you cannot see on screen: dozens to hundreds of packages the project is built from, which somebody has to keep updated; a hosting configuration; a database with access rules, or without them; keys to third-party services written into files; a privacy policy generated "along the way" that describes a website you do not have.

"The code is yours" means you can download it. It does not mean you can read it, that you know what it does with data, or that anyone has ever checked. It is like getting a car with no inspection: it drives, but nobody has looked under the hood.

Then there is the pricing, which looks innocent enough. As of September 2026, Lovable on the Pro plan costs $25 a month for 100 credits, Bolt on Pro also $25, and v0 on Plus $30 per user - so on the order of €25-30 a month, depending on the exchange rate. Credits, though, are not months. You pay per attempt, not per result, and reviews of Lovable consistently note that a hundred credits on a mid-sized project vanish faster than you would expect. Hosting and a database, once the project grows, are a separate bill.

5 risks the tutorials do not mention

1. Security - the code runs, but nobody has checked it

This is not theory. Veracode, in its GenAI Code Security 2026 report, tested how AI models handle programming tasks: around 44% of generated solutions contained a security flaw, and in 85% of cases the code failed to defend against one of the oldest attacks on websites (XSS). The year before it was 45%, so nothing is improving despite better models.

Closer to the subject still is the Escape.tech study from 2026. The team scanned 1,400 publicly reachable applications built in Lovable, Bolt and similar tools. The result: over 2,000 highly critical vulnerabilities, more than 400 leaked secrets (API keys, tokens) and 175 instances of personal data left in plain view, including bank account numbers.

And a concrete case from this year. In February 2026 a researcher demonstrated 16 vulnerabilities in a single Lovable app, six of them critical, with the app exposing the data of more than 18,000 people. In parallel, the platform itself was patching a flaw in its own backend that gave access to other people's project code, credentials and chat history. I am not writing this to say "Lovable is bad". The platform responded. I am writing it because this is what risk looks like in a model where nobody reviews anything before the site starts collecting data.

What to do about it: before you hook up a form that takes personal data, ask someone who reads code for one review. If you have a database, have them check that every table has access rules, not just the first one. Service keys must not sit in the code. On a static site it comes down to three things: a form handled by a proven third-party tool, no keys in files, HTTPS.

2. GDPR - you are the controller, even if AI wrote the code

A contact form, appointment bookings, a newsletter: that is processing personal data. The controller is answerable for it, meaning your company. Not Lovable, not OpenAI, not the host. A generated privacy policy usually describes something other than what the site actually does: it does not know where the database physically sits, who the processor is, or how long you keep the data.

Two things are worth checking yourself, without a lawyer. First, the servers: which region the site and the database sit in (Supabase, Vercel and the rest let you choose, but AI picks the default) and whether data leaves Europe without a legal basis. Second, cookies and scripts: generated code has a habit of pulling in third-party scripts - analytics, fonts from Google's servers, maps, a chat widget - that set cookies before anyone has consented. A consent tool like Cookiebot or similar can handle that, but first somebody has to know those scripts are there at all.

I am not a lawyer and this is not legal advice. This post only shows you where the questions are. The Panoptykon Foundation has written up how GDPR fits into building software, which is a good starting point for a conversation with someone who does this for a living.

3. Maintenance - who updates this in six months

A Lovable or v0 app is a React or Next.js project with dozens of dependencies that ship security patches every week. In WordPress, updates are a click in the admin panel - still required, but a click. In a generated code project, updates happen in the code, and the first incompatible package version stops everything and sends you back to prompting.

Reviews of these tools describe the same pattern: on a small project AI does brilliantly, but the deeper in you go, the harder it gets to keep control of how the pieces depend on each other, and every change in one place breaks something in another. That is not a statistic, it is the experience of people who tried.

What to do about it: either someone who understands the code takes the project into their care - a cost comparable to a WordPress care plan, in the region of €320-600 a month - or you knowingly accept that the site has an expiry date.

4. Cost - credits, hosting and "just one more prompt"

The mechanic the price list does not show you: every fix costs credits, including "move the button to the left". When AI hits a bug it cannot fix, credits burn in a loop while you spend a third evening on the same problem. It is the single most common complaint in reviews, local and international.

Let us count it honestly, using the method from the post about the bill after two years. The tool plan is about €25 a month, hosting and a database on top once the project grows, plus your own evenings. Vibe coding is cheaper in cash at the start almost every time, and no developer should tell you otherwise. It gets more expensive at exactly one moment: the first failure you cannot fix yourself. That is when you pay for diagnosing code with no author, and in a familiar technology that usually costs more than building the same thing from scratch. I wrote about that mechanism at length in why good websites did not get cheaper: the tool got cheaper, the responsibility did not.

5. Nobody owns the problem

This risk ties the other four together. In a builder, the platform is answerable for the site working, within its terms. With a developer, the developer is, with a contract, a warranty and a care plan, the way I describe it in my process. In vibe coding, you are. Without the tools to carry it, and often without knowing there is anything to carry.

None of these five risks is "a flaw in Lovable". They are the limits of a model where code gets written without being read. Limits, not flaws. And there are situations where those limits do not matter in the slightest.

When vibe coding is enough (and I say that without flinching)

Not every project needs someone like me. Vibe coding is a good choice, and sometimes the best one, when:

• you are building a prototype to show an idea to a business partner, an investor or your first customers - here iteration costs minutes and commissioning it makes no sense,
• you are building an internal tool for three people in the company, with no customer data: a calculator, a checklist, a simple task board,
• you are putting up a landing page with no form, or with a form handled by a proven third-party tool, for one season,
• you want to understand how your digital product works before you commission it - a generated site is the best brief you can bring a developer,
• it is a hobby project where an outage costs nobody anything.

If that is your case, you do not need me. A few pieces of advice for the road, so this does not become your problem a year from now: do not collect data you do not need. Wire the form through a proven third-party tool instead of your own database. Never leave service keys in the code. Export the code to your own repository from day one. And before you connect anything that touches customer data, ask someone who reads code to look at it once.

Signs it is time to hand it to someone who reads code

The mirror image of the previous section. Five signs the generated site has stopped being a prototype:

1. The site collects customer data - a form, bookings, accounts - and nobody has checked who can get at it.
2. "Just one more prompt" is into its third evening, and the bug keeps coming back.
3. You want to connect payments, invoicing or an integration with the software the company runs on.
4. The site is meant to rank in Google for service queries, which takes control over structure, speed and schema.org data - and on why that now applies to AI assistants too, see Wix vs WordPress.
5. You are counting credits and evenings, and the total is closing in on a developer's quote.

What then? Two routes, both honest. The first is a review and takeover of the existing code, which makes sense when the project is small and clean. The second is a rewrite onto a proven technology, keeping the content and the URLs, the way I handle a rebuild without losing SEO. In both cases the generated site is still the best brief a developer can be handed. None of those evenings goes to waste.

Already have a site like this? A checklist for today

Seven points you can check yourself, with no technical knowledge:

1. Does the form send data over HTTPS? Look for the padlock next to the address in your browser. If it is not there, do not collect anything.
2. Are service keys sitting in the code? Download the project and search the files for the words "key", "secret", "token". If there are long strings of characters next to them, you have a problem.
3. Does every table in the database have access rules? In Supabase that is the "Policies" tab - every table holding data should have them, not just the first one.
4. Does the privacy policy name real providers? Hosting, the database, the form tool, analytics. If it names "our company" and nothing else, it was generated, not written.
5. Does the site set cookies before consent? Open it in a private window, go into your browser's developer tools, cookies tab. Or add a consent banner like Cookiebot, which detects the scripts for you.
6. Do you have a copy of the code outside the platform? A GitHub repository, or at least an archive on a drive. If not, the site exists only as long as your account does.
7. Do you know who picks up the phone when the site goes down? If the answer is "nobody", you do not have a website. You have an obligation you do not know about yet.

If you ticked all seven, your AI site is in better shape than most. If you got stuck on point two or three, go back to the section on the warning signs.

Summary

Vibe coding is the best way to build a prototype and the worst way to pretend you have a product. The difference is not in the tool, it is in whether somebody reads the code and answers for the result. If a site is going to collect data and make money, somebody has to own it - in the sense of responsibility, not licensing.

If you are not sure which side of that line your project falls on, book a free consultation. Come with a link to what you generated. I will tell you whether one review is enough or a rebuild is needed - and if it is a prototype doing its job, I will tell you to change nothing.