Website Design and Development

We Built This Website With AI: What Actually Worked and What Didn't

This site's actual build timeline - audit, scaffold, build, audit again, deploy - with three real bugs marked at the stage a developer caught them

“Can you really build a website with AI?” is usually asked about drag-and-drop builders like Wix or Squarespace, and for that category the answer is a straightforward yes - plenty of perfectly good small business sites get built that way every day. This is a different, more specific claim: a full custom site, hand-coded in Astro, deployed on Cloudflare, built with AI doing a large share of the actual work, reviewed and corrected by a developer throughout. This is that site, and this is the honest account of how it actually went.

What the AI-assisted build actually involved

Recovering and auditing a decade of legacy content - a WordPress database export cross-referenced against 1,029 archived URLs from the Wayback Machine - and deciding, page by page, what to redirect, retire, or rewrite. Scaffolding a new Astro project with content collections, a design token system built from a real brand palette, and a Cloudflare Workers deployment pattern. Writing every page, component, and piece of content. Running a full accessibility and performance audit, finding and fixing real issues, and verifying the fixes actually worked. None of this happened in one uninterrupted pass - it was built, checked, corrected, and rebuilt, the way any real project goes.

What genuinely worked well

Mechanical, well-specified work moved fast: scaffolding the project structure, writing component markup against a clear design brief, generating a consistent pattern across many similar pages once the first one was verified correct, cross-referencing a large archived URL list against a database export. Research that would be tedious and error-prone for a person to do by hand - matching patterns across a thousand archived URLs, digesting dense structured research data - is exactly where AI assistance earned its keep.

What genuinely went wrong, specifically

A wrong default that looked completely reasonable. Cloudflare’s deployment config needs a pinned compatibility_date. Left unprompted, the natural-seeming choice is “today’s date” - which is wrong, because it means deploy behaviour silently depends on when the file was generated rather than a deliberate decision. Caught and fixed only because it was already a known gotcha from a previous project, not because anything about the generated config looked obviously wrong.

A bug invisible in the tool that wrote it. A line break before a templated expression collapsed whitespace in the compiled HTML - correct-looking in the source, correct-looking in the live dev server, wrong only in the actual built output. Caught by deliberately diffing built HTML files, which isn’t something you’d normally think to do unless you’d been burned by exactly this before.

A plausible, wrong URL. An AI-drafted article linked to a service page URL that didn’t exist - close enough to the real one to read as correct, wrong enough to be a dead link. The build succeeded. Automated accessibility and performance checks both passed, because neither one follows outbound link targets. Caught only by a deliberate link-check step added specifically because this is a known AI-content failure pattern - confident, plausible, and wrong.

What this actually means

None of the three mistakes above were conceptual failures - the AI assistance wasn’t confused about what it was building. Each one was a locally correct, plausible-looking output that only revealed itself as wrong from a wider context: specific prior experience with a known gotcha, a check against actual compiled output rather than source, a deliberate verification step built in because the failure mode is known to exist. That’s a genuinely different shape of risk than “the AI doesn’t understand web development” - it understands plenty. What it doesn’t do on its own is know which specific plausible-looking output to distrust, which is still a developer’s job.

The honest verdict

Yes, you can build a real, custom, production-quality website this way - this one is the proof, not a claim. It also isn’t “point AI at a brief and get a finished site.” It’s AI assistance inside a normal development process, with someone who knows what to check doing the checking, every step. The parts people worry about (will it be generic, will it be broken, will it be slow) are solvable; the solving is still a developer’s job, not something the tooling does unsupervised.

If you’re weighing whether this approach is right for your own project, we’re glad to talk through exactly what it would involve for your specific site - get in touch via our website design and development page.

← Back to Insights