I need to say something that might be unpopular: I genuinely admire what vibe coding has done.

The ability to describe a website in plain English and watch it materialise in front of you is extraordinary. Tools like Cursor, Bolt, Replit, and Lovable have made it possible for someone with no programming background to produce a working prototype in minutes. That's not hype — it's a genuine shift in what's possible.

A quarter of the startups in Y Combinator's Winter 2025 batch had codebases that were 95% AI-generated. Collins Dictionary named "vibe coding" its Word of the Year for 2025. The barrier to getting something live has never been lower.

But here's where the story gets complicated. I've used vibe-coded websites myself. The initial experience was electric — a site that looked credible, functioned properly, and existed almost immediately. Then I tried to do SEO work on it. I couldn't find where things lived. I couldn't control the heading hierarchy. I couldn't trace which files governed which sections. The architecture wasn't bad — it was absent. What looked like a building was actually a stage set.

And that's the distinction this post is about. Not whether AI can build websites — it obviously can, and I build with it. But whether what it produces can survive the things that come after launch: content updates, SEO, accessibility compliance, security requirements, stakeholder scrutiny, and the quiet accumulation of maintenance decisions that determine whether a site is infrastructure or disposable.

The cost moved — it didn't disappear

The promise of vibe coding is that it eliminates the cost of building. And for prototyping, that's largely true. But for anything that needs to be maintained, the cost hasn't disappeared. It's relocated.

Every content change on a vibe-coded site requires a prompt. Every prompt consumes tokens. Output tokens — the code the AI writes back to you — are typically more expensive than input tokens. Even at the cheapest tier, a team making regular content updates through an AI coding tool is paying per interaction, indefinitely.

Compare that to a site built to be edited. Your Communications Director opens the editor, changes a paragraph, and publishes. No prompt. No tokens. No risk of the AI rewriting your navigation whilst fixing a typo. The cost of that edit is zero — because the architecture was designed to make content updates a governed, independent action rather than an AI transaction. That is true of a platform CMS and it is true of a custom build with a form-based editor; what it is never true of is a site where editing means prompting.

The barrier to entry for building hasn't lowered. It's shifted from build time to edit time. And the people bearing that edit cost are often the least technical members of the team — the ones who were told AI would make everything easier.

Using AI without prior knowledge is expensive

This is the part that rarely gets discussed. Vibe coding tools respond to the quality of the prompt. An experienced developer who prompts an AI to scaffold a component gets better output than someone who's never written a line of code.

The AI doesn't fill in the gaps in your knowledge. It amplifies whatever understanding you bring to the conversation. If you don't know what WCAG AA compliance requires, the AI won't build it in by default. If you don't understand what a heading hierarchy is, the AI will generate one — but it might be semantically meaningless. If you don't know what schema markup does, you won't think to ask for it.

The result is that people without prior technical knowledge burn through tokens at a higher rate — prompting, getting wrong output, re-prompting, getting slightly less wrong output, and eventually accepting something that looks right but isn't. The AI is a brilliant tool in the hands of someone who already understands web architecture. For everyone else, it's a very expensive guessing game.

This is precisely why a consultant who understands your institutional context matters more, not less, in the age of AI. The value isn't writing the code. It's knowing what to ask for.

The security problem nobody warned you about

In May 2025, a security researcher published a scan of 1,645 web applications built using the vibe coding platform Lovable. Of those, 170 — roughly one in ten — had critical security vulnerabilities that exposed users' personal data. The leaked information included names, email addresses, phone numbers, payment details, and API keys. The vulnerability was severe enough to earn a formal CVE designation (CVE-2025-48757) and a critical severity score of 9.3 out of 10.

The root cause wasn't exotic. It was a database configuration that the AI had generated without proper security rules. The people who built those applications had no idea their users' data was exposed, because they'd never been taught to check. Lovable later introduced a security scanner — but it only checked whether a security policy existed, not whether it actually worked.

These aren't edge cases. Research repeatedly finds security vulnerabilities in AI-generated code.

For any organisation that handles donor data, beneficiary information, or payment processing — which is to say, every nonprofit with a website — this is an institutional risk that no amount of speed justifies. Security isn't a feature you bolt on after launch. It's an architectural decision that needs to be made before a single line of code is written.

A governed build closes that gap from either direction. A custom static site publishes plain files: there is no database to misconfigure, no plugin to patch and no admin login sitting on the public server, so most of the categories of risk above simply do not exist. A managed platform like Webflow reaches the same place by taking the hosting on itself — SSL certificates handled automatically, no server-side plugins, no environment for the site owner to maintain. Neither is magic. In both cases the attack surface is smaller because somebody decided the security model deliberately, instead of accepting whichever one a prompt happened to generate.

Nobody owns the architecture

One of the most revealing accounts of vibe coding came from a Stack Overflow writer who built an app using Bolt. It took about ten minutes to create. It looked great. It also didn't work — error messages appeared immediately. When experienced developer friends reviewed the code, their main feedback was that it was messy and nearly impossible to understand.

This is a pattern I see consistently. The AI generates something that functions in demo conditions, but the underlying structure was never designed — it was assembled. There's no consistent naming convention. No documented component system. No logical separation between layout, content, and behaviour. The code works, but it can't be maintained by anyone who didn't prompt it into existence — and often not even by them.

Simon Willison, the creator of Datasette and one of the most thoughtful voices on AI in development, put it plainly: vibe coding may work for throwaway weekend projects, but most of what we do as engineers involves evolving existing systems, where the quality and understandability of the underlying code is crucial.

For a nonprofit website that needs to serve multiple stakeholder groups — institutional funders checking governance credentials, donors completing donation flows, beneficiaries accessing service information, regulators verifying compliance — the architecture isn't a technical detail. It's the mechanism that makes all of those journeys possible simultaneously. When nobody owns that architecture, nobody can guarantee any of those journeys work.

What a governed build actually gives you

The opposite of a vibe-coded site is not a site built without AI. It is a site somebody designed, owns and can hand over. There are two routes to it, and I use both: a custom build in code, which is what I recommend first now, and Webflow where an organisation already has it.

What they have in common is the part that matters.

Content you can edit without writing a prompt. A CMS on a platform, or a form-based editor writing to typed fields on a custom build: a headline, a date, a summary, an image with its description. Either way your team changes content and cannot reach the layout, the heading structure or the colours.

An architecture with names. Components that exist on purpose, a predictable URL structure, a heading hierarchy that means something. When I run a technical SEO audit on a site built this way, I can find where things live. When I tried the same on a vibe-coded site, I spent more time working out what the AI had generated than it would have taken to build the thing properly.

Accessibility as a structural property. On a custom build the checks run on every page, every time the site is built, so a missing image description stops the release rather than waiting for an annual audit. On Webflow, the Lumos framework does the same job at the component level. Both are WCAG AA by construction rather than by remediation.

A written governance framework where roles, permissions and editorial workflow are explicit, rather than living in one person's head.

And three things specific to a custom build, which are the questions to ask anyone who proposes one:

  1. a framework other developers know, so the site is not tied to the person who built it;
  2. a repository your organisation owns, so the code is an asset rather than a favour;
  3. written instructions in that repository for whoever works on it next, person or AI tool.

A custom build with those three can be handed to another developer on a Monday morning. A custom build without them is the risk this post is about — and so is a vibe-coded one, for exactly the same reason. The tool that produced the code is not what decides this. The setup around it is.

The honest position

AI is excellent technology. I use it daily, and not only for copy and research: I write code with AI coding tools, review every change, and stay accountable for what ships. This site is one of the results. The difference between that and a vibe-coded site is not the tool — it is that somebody chose the framework, owns the repository, wrote down how it works, and signed off every line that went live.

The problem is AI as architect — as the thing that determines the structure, the security model, the accessibility foundation, and the maintenance workflow for a website that an organisation depends on. That's not what AI is good at, and pretending otherwise creates institutional risk that compounds silently until something breaks publicly.

If you're a Communications Director at an NGO with £500K to £10M in annual income, your website isn't a side project. It's institutional infrastructure that donors scrutinise, funders audit, regulators check, and your Board is accountable for. The question isn't whether you can build it with AI. The question is whether you can govern it.

The first step in rehab is admitting that a website isn't a product you build once. It's infrastructure you maintain. And maintenance requires architecture, ownership, and a platform that was designed to support it — not one that was prompted into existence and hoped for the best.

If your organisation's website is approaching a period of scrutiny — leadership transition, funding growth, regulatory attention — and you're not confident in what donors and funders see when they visit, the Blueprint Audit is designed to give you that clarity. It's a structured diagnostic that identifies what's actually failing, maps your stakeholder priorities, and produces a Board-ready report with specific findings. It stands alone, with no obligation to build, and the report is yours regardless of what comes next.