The website you are reading was rebuilt this year, and the way we did it says a lot about how Netcraft approaches engineering. The old site ran on WordPress, as most small-business sites do. WordPress is fine software, but for what is essentially a static marketing site it means a database, a PHP runtime, an admin panel on the public internet, and a plugin ecosystem that needs patching forever. Ours also carried the sediment of every brand consultant who had ever worked on it — page builders stacked on page builders, so a simple copy change meant clicking through someone else's nest of modules and hoping nothing shifted. Editing the site was no fun, and it showed.
We had a long wishlist of pages and articles that nobody wanted to write, because nobody wanted to fight the tooling.
We wanted the maintenance profile of a static site without giving up the ability to change things quickly.
Step one: a pixel-level clone
The look of the site was the one thing we did not want to lose. After being disappointed with what the experts delivered, we had put many hours into the design ourselves, and it had earned its keep — the problem was the platform it was welded to. So rather than redesign from scratch, we pointed a Claude agent at the existing WordPress site and asked it to reproduce the thing exactly: layout, typography, colours, image placement, down to the pixel. That gave us a faithful copy of a design we liked, decoupled from WordPress. It also gave us a clean baseline: every later change was a deliberate decision, reviewed in a diff, not an accident of migration.
Step two: reimplement it in our stack
The clone then became a real application: Next.js with TypeScript, React and Tailwind, statically generated and shipped as a single container. There is no CMS database behind it. Page content lives in typed data files in the repository, and posts like this one are Markdown, so "editing the website" is the same act as editing code — open a merge request. Every page is rendered at build time, which is why the site is fast, and why its public attack surface is a static web server rather than an application stack. The build fails if content breaks the rules we have set for it, from SEO metadata limits to malformed frontmatter.
That wishlist is finally shrinking. Our head of sales, Adam, is getting back to his engineering roots and can update content easily and safely at any time — the pipeline catches mistakes before they ship, so a content change is a five-minute job instead of a careful expedition through page builders.
Step three: the polishing pass
A pixel-perfect clone can still be scrappy under the hood, so the next pass was about craft. Geoffrey went over the rebuild meticulously — fresh from a React and JavaScript course — and fed Claude examples of his chef's-kiss components: here is what a component should look like, now make the rest of the codebase match. That division of labour works well.
One engineer sets the bar, and the agent applies it everywhere without getting bored or cutting corners on file forty.
Step four: an SEO strategy we can keep
SEO is something we have honestly never understood, so this time Adam
sat down with Claude and designed a strategy properly: analysing the
brand, the services, and where we operate, then deciding which
searches each page should answer. Claude made all of the changes —
titles, descriptions, structured data, sitemaps, and the newer
signals that AI answer engines read — and it maintains an SEO.md
file in the repository documenting the whole architecture. That last
part matters most: anyone updating a page now inherits the keywords
and the design instead of accidentally undoing them.
The SEO is now so good that experts email us every week offering to help with it.
Step five: ship it like software
The site lives in git on our Forgejo instance, and Forgejo Actions
runs the pipeline. Changes go up as merge requests and get code
review; dependencies are scanned for known vulnerabilities; merges to
the main branch build the container and deploy it to an
access-controlled staging server; and promoting to the live branch
deploys the same image to production. Rolling back is redeploying a
previous image.
There are no FTP uploads, no in-place edits on the server, and no way for the production site to drift from what the repository says it should be.
None of this is exotic — it is the workflow we use for the software we build for customers, applied to our own shopfront. The interesting part is how much of the initial work an AI agent did under engineering review: the clone, the reimplementation, and a good deal of what has shipped since, including the blog engine these posts run on. That mix — agents for the long, careful work, engineers for the judgement — is where we have landed for our own tooling, and it is the same way we now approach software development for customers.
If your organisation is carrying a web stack that costs more care than it gives back, we can help.