From WordPress to Claude Code — what we learned

Since you're reading this, you're looking at the result. In April 2026 we decided to rebuild allegroit.dk from scratch. The old site was a WordPress installation with Elementor, Polylang and eight active plugins on a shared host. The new site — the one you're on now — was written by hand by Claude Code as plain PHP, runs in a single Docker container on a VPS in Helsinki, and has no database, no admin panel and no plugins at all.

This isn't a technical exercise for its own sake. We sell AI-assisted development as a service, and the best argument we could find was to do it on our own site first. Here's the scorecard — speed, file count, database, security — and what we had to give up to get here.

How the work was split

Before the numbers it's important to be honest about who did what. Otherwise the story becomes "AI built a website" — and that's not quite true.

The practical flow: we wrote the original text material ourselves — everything we know about our own services, clients and references — and Claude polished the language, structure and tone. Claude wrote the code from scratch following our technical direction, and we reviewed every commit before it was pushed. The design evolved through conversation: we described what we wanted; Claude proposed layouts and implemented them; we got the result in the browser and asked for adjustments. The result was around 125 files and a fully functioning bilingual marketing site.

The new stack, in short

• One Alpine container running PHP 8.3-FPM + nginx + supervisord
• Parsedown for Markdown rendering — no CMS
• Content in git: every page and post is a .md file with frontmatter
• Bilingual via filename: post.da.md + post.en.md, no Polylang
• No database: backup is git push, rollback is git reset --hard
• Deploy via GitHub Actions to Hetzner → docker compose up -d

A fresh git clone + docker compose up gives you a fully working site in under 30 seconds. The old WordPress site couldn't be deployed without also importing a SQL dump and re-activating plugins in the right order.

How much time did it take?

Roughly 15 hours of work in total — from the first commit to a live production site. That's falsifiable; git log is public. And that's everything, not a subset:

• Layout design and implementation: header, footer, homepage, service pages, post archive, single posts in two display styles
• Migration of all content from WordPress to Markdown — pages, posts, references, images
• Bilingual routing with DA↔EN slug pairs and a language switcher
• Contact form with server-side validation and SMTP via Microsoft 365
• GDPR-compliant log handling, privacy policy and cookie notice banner
• Deploy pipeline: GitHub Actions → Docker build → Hetzner
• SEO metadata, JSON-LD, sitemap, robots.txt and llms.txt for AI crawlers
• HTTP security headers (which took us from grade D to A)
• Favicon generation, logo cropping, Open Graph images

From empty git repo to a complete, bilingual, secure, production-ready marketing site — all in 15 hours. That's the actual cost of what we sell, and a number any potential client can use to work backwards on what a similar solution would cost them.

What did it look like in numbers?

We measured both sites in production on the same day — allegroit.dk on WordPress and the new stack — and pulled the numbers from Chrome's Performance API rather than guessing. Here's the short overview:

The most important number to understand is TTFB (Time To First Byte) — how long the server thinks before it starts sending a response back. 325 ms vs. 123 ms isn't about hosting; it's about WordPress having to boot its entire core, load eight plugins and run 30+ SQL queries before it can even write the first character. The new stack reads one Markdown file, renders it, and is done.

Security: from no headers to an A

That was a side benefit we hadn't expected. When we measured both sites, neither had the modern HTTP security headers turned on. The WordPress site had only X-Content-Type-Options (Simply.com sets that one automatically). On securityheaders.com that earned grade D.

On the new stack, adding the full set — HSTS, Content-Security-Policy, X-Frame-Options, Referrer-Policy, Permissions-Policy — took one commit and ten lines of nginx config. We went from nothing to grade A.

The difference isn't that we're especially skilled — it's a tier change in how easy it is to change anything. On a WordPress site on shared hosting, you need your host's cooperation to change nginx headers. For us, it's two files in git and a docker compose up -d.

What couldn't we measure?

To be honest: everything above is numbers you can read off a browser. Those are the easy things. There are three things we deliberately haven't tried to put in the scorecard:

1. SEO — the new site has technical advantages (faster, smaller, correctly structured JSON-LD, hreflang, llms.txt for AI crawlers), but what matters is how Google ranks it in three months. We can't measure that yet.
2. Usability — whether visitors find what they're looking for, and whether they call us afterwards. We'll have to ask clients about that.
3. UX and design quality — does it look nice? That's subjective, and the one we'd like to ask is you, reading this.

If you've looked through the new site and have feedback on any of the above, get in touch — that's the kind of input we can't measure our way to.

What about WordPress's classic advantages?

The traditional list of WordPress advantages usually comes down to three things: a WYSIWYG editor anyone can use, a huge plugin ecosystem, and 20 years of familiar ground. We've thought about each of them — and in 2026 they carry much less weight than they used to.

1. "Anyone can edit in the WP admin". That's a truth with caveats — and there's a reason it's mostly web agencies that build and maintain WordPress sites. In practice the WP admin still needs a technical person: Elementor and other page builders have their own learning curves, plugin updates break things on a regular basis, conflicts need resolving, backups need running, and SEO and security plugins need configuring. The "anyone can edit" promise is mostly marketing — most WP clients end up calling their agency when anything non-trivial needs changing.

   And once you already have a developer (or an agency) in the loop, the argument shifts considerably. Git is actually better than WordPress for multiple concurrent editors — two people opening the same page in the WP admin create conflicts and lost edits, while git merges cleanly and leaves a revision history down to the line. Markdown is easy to learn for anyone who's even slightly technical. And most importantly: nobody needs to write the changes themselves. Describe what needs doing in plain English — "update the price in the table, add a new reference, swap the image" — and Claude Code handles the rest, creates a commit and pushes. The WYSIWYG editor solves a problem that's no longer a problem.

2. "There's always a plugin for it". WordPress has a plugin for almost everything — and that's also what gives you eight external codebases in your installation, each with its own attack surface, update cadence and CVE tail. When you instead ask Claude to build a feature made specifically for your site — booking, newsletter signup, filters, whatever it is — you end up with something smaller, faster and more precise than a general plugin that has to cover everybody's use cases. The question is no longer "is there a plugin?", but "can it be built quickly?" — and the answer is typically yes.

   A concrete example from a WordPress site we worked on for a client: the site was firing duplicate API requests — the same call several times per page load. We tried to debug it with AI help and had to give up. Not because the AI wasn't good enough, but because the code wasn't ours — it was a handful of plugins each hooking into WordPress's hooks without knowing about each other. You can't fix something you don't own. On a stack like this one, Claude Code has full access to a codebase we wrote every line of; that kind of debugging is trivial.

3. "When WordPress breaks, you can Google your way to the answer". That's true — WordPress is 20 years old, and there's plenty of help out there. But when your site breaks, you don't want to Google; you want it fixed. That's exactly the kind of maintenance we do for clients. If you're running a plain-PHP solution built with Claude Code and it starts behaving oddly one day, call us. Response time within 24 hours.

Could you use something similar?

If you have an old WordPress site that's gone slow and hard to maintain — or if you're considering building a new marketing site from scratch and are curious how quickly it can go with Claude Code in the driver's seat — tell us about your project. We'll get back within 24 hours with a no-obligation proposal.

And if you'd like to go deeper into the numbers — the full measurements, methodology and side-by-side comparison — you can download the full efficiency comparison report as PDF.