Can I build my business website with Base44, Lovable or Bolt?

You can, and for a prototype or an internal tool it is a good use of them. The risk shows up once real customers are involved: silent form failures, no spam protection, secrets left in client-side code, and nobody in the loop who can explain what the code does when it breaks. If the site is how customers find and contact you, it is worth having someone who can read the code involved.

Is vibe-coding a website safe?

The generated code is usually reasonable. The exposure is that nobody can verify it. If you cannot say where your API keys are stored, what happens to a contact form submission, or what stops a bot submitting it ten thousand times, then no one can tell you whether the site is safe — or fix it quickly when it is not. That is a different problem from simply being non-technical.

How do I check whether my AI-generated site has these problems?

Run the 12-point production checklist — it takes an afternoon, requires no code, and covers the failures that actually cost money. The four that matter most: submit your own contact form and confirm the enquiry arrives, view your page source and search for exposed keys, check the site on a real phone on mobile data, and run it through Google PageSpeed Insights.

Building software by prompting an AI tool and accepting what it generates, without a working understanding of the code underneath — steering by whether it looks right rather than by reading what was actually written. The term was coined by AI researcher Andrej Karpathy in February 2025. It is a genuinely useful way to move fast on personal projects and experiments.

Should I rebuild my vibe-coded site or fix it?

Usually rebuild, and it is often cheaper despite sounding bigger — reading generated code you did not write is slower than writing it cleanly, because there is no design intent to reconstruct. The exception is a site that basically works with one narrow problem, like a broken form or a speed issue, where a targeted fix is the right call.

Should you vibe-code your business website?

AI tools can generate a working-looking site in minutes. Here's what actually breaks once real customers — not just you — start using it.

The short answer

For a prototype, an internal tool, or proving an idea this weekend: yes, and the tools are good at it. For the website your enquiries depend on: the risk is not that AI writes bad code, it is that nobody in the loop can verify it. If you cannot say where your API keys live or what happens to a form submission, nobody can tell you whether the site is safe — or fix it quickly when it is not.

If you have already built one and want to check it yourself, the 12-point production checklist takes an afternoon and needs no code.

What “vibe-coding” actually means

Vibe-coding is building software by prompting an AI tool — Base44, Lovable, Bolt.new, Vercel v0, Replit, Cursor — and accepting whatever it generates, without a working understanding of the code underneath — you’re steering by “does this look right,” not by reading and reasoning about what was actually written. For a personal project or a weekend experiment, that’s a genuinely useful way to move fast. For the website a business depends on for enquiries, it’s a different kind of risk than most owners realise they’re taking on.

The problem isn’t the AI. Modern models write reasonable-looking code. The problem is that “reasonable-looking” and “correct under real conditions” are two different things, and nothing in the vibe-coding loop checks for the gap between them. A model has no way to know your contact form needs to survive a bot scraping it a thousand times an hour unless someone who understands that risk asked it to handle that case specifically.

The real risk isn’t the code — it’s not knowing what it’s doing

Here’s the part that’s easy to miss: vibe-coding doesn’t just mean you didn’t write the code, it means nobody involved can actually explain it. Ask yourself what your contact form does with someone’s details after they hit submit, where any API keys are stored, or what happens if two people submit it at the same moment. If the honest answer is “I don’t know, the AI just handled it,” that’s the real exposure — not any one bug, but the fact that no one understands the system well enough to know if it’s safe, or to fix it quickly when it isn’t.

That’s a different problem from simply being non-technical. Plenty of business owners who commission a hand-coded build didn’t write a line of it either. The difference is whether someone in the loop actually does understand it — vibe-coding is specifically the case where no one does.

What actually breaks once real customers show up

A demo only has to survive the one path you tested — you typed a normal name into the form, it worked, you moved on. A live business site has to survive everyone: someone who pastes an email address with a typo, someone on a slow mobile connection in a lift, someone using a screen reader, someone who submits the form twice by mistake, someone typing an emoji into the phone number field.

AI-generated code optimises for the happy path because that’s the path you prompted and tested. The unhappy paths — the ones that don’t show up until a stranger uses the site in a way you didn’t imagine — are exactly what a working understanding of the code would normally catch, and exactly what gets skipped when nobody’s actually reading it.

The same pattern shows up in a few specific places:

Input handling. Forms that don’t validate or sanitise what’s typed into them are a genuine security exposure, not just a bug — this is the same class of issue as SQL injection and cross-site scripting, categories that have sat in the OWASP Top 10 for over a decade because they’re still common.
Silent regressions. Without tests, asking the AI to fix one thing can quietly break another — there’s nothing catching it before a customer does.
Accessibility. Colour contrast, semantic HTML, keyboard navigation — easy to skip entirely when nobody’s specifically checking, and each one is a real customer who can’t use your site.
SEO fundamentals. Meta tags, semantic structure, proper heading hierarchy — the same technical foundations covered in why hand-coded sites rank better, often missing or wrong in generated output because nobody asked for them explicitly.

Why this matters more for a business site than a side project

A side project failing costs you an evening. A business site failing costs you the enquiry that would have come in while it was broken — and you often don’t find out until you notice bookings have quietly dropped.

The deeper issue is what happens when something does go wrong. With a side project, “just re-prompt it” is a fine recovery plan. With a business site, you need to know why it broke, not just get something that looks fixed — and that requires someone who actually understands what’s running, not just someone who can describe the symptom to a chat window.

What happens six months later

The gap between a vibe-coded site and a hand-coded one is usually invisible on launch day, because both can look identical in a browser tab. It shows up the first time something needs to change: a new service added, a pricing update, a plugin or dependency that needs updating for a security patch.

On a hand-coded site, that change is scoped, tested, and shipped by someone who understands what else it might touch. On a vibe-coded one, the only available move is re-prompting and hoping nothing else quietly broke, because there’s no one who can trace the actual dependency between the piece being changed and the rest of the system. Small changes start to feel disproportionately risky, and that risk compounds every time a new feature gets bolted on the same way.

There’s a security dimension to this too, not just a maintenance one. AI models and the libraries they lean on get updated constantly, and some of those updates are patches for real vulnerabilities. A hand-coded site with an engineer attached gets those patches applied deliberately. A vibe-coded site sitting untouched since launch doesn’t get patched at all, because nobody’s watching for the advisory in the first place.

Where AI tools are genuinely useful in a real build

None of this is an argument against AI tools themselves; it’s an argument against using them unsupervised for something a business depends on. In a properly built site, AI assistance is a genuine productivity gain for scaffolding, drafting boilerplate, and exploring options fast, with an engineer reviewing and understanding every line before it ships.

The distinction that actually matters isn’t “was AI involved,” it’s “did a human who understands the code review what it produced before a real customer touched it.” A hand-coded build can use AI throughout the process and still be fully accountable, because the person building it can explain every decision the tool made a suggestion on. A vibe-coded build skips that review step entirely, and that’s the step where the unhappy paths actually get caught.

How to check if this is already a problem for you

You don’t need to take this on faith. A few five-minute tests on your own site:

Submit your own contact form with unusual input — an emoji in the name field, a very long string, an empty required field. See what actually happens, not what you assume happens.
Run Lighthouse’s accessibility audit (built into Chrome DevTools) and look at the score, not just whether the site “looks fine.”
Ask yourself honestly: if the site broke at 11pm the night before a big campaign launch, could you fix it yourself, or would you be stuck re-describing the problem to a tool and hoping?

If any of those give you pause, that’s the actual cost of vibe-coding a production site — not a hypothetical one. None of these tests take more than a few minutes, and none of them require you to understand code yourself — you’re checking behaviour, not reading source.

Common vibe-coding myths

Myth	Reality
“AI-generated code is basically production-ready”	It’s a first draft — it optimises for looking done, not for surviving edge cases nobody tested
“If it looks right, it works right”	Visual correctness and functional correctness are different things; AI tools are strong on the former, unreliable on the latter
“I can just keep prompting until it’s fixed”	Every new prompt risks silently breaking something unrelated — there’s no test suite catching the regression before a customer does

The honest trade-off

Vibe-coding is genuinely good at what it’s for: prototypes, internal tools, learning, throwaway experiments. The problem isn’t the tool — it’s using a prototyping tool for a production asset your business’s enquiries depend on, without an engineer actually reviewing what it produced.

See our custom web design page for how a hand-coded build avoids this entirely, or our pricing for how a build is paid for — usually less than people expect. If you’ve already got a site built this way and aren’t sure how exposed it is, that’s a fast, free conversation, not a sales pitch.

The trade-off is much the same if you’re weighing a bargain quote from a task marketplace instead of an AI tool — see why not just hire a cheap developer from Airtasker or Fiverr? for what that price difference is actually paying for.