An accountancy practice paid an agency $9,000 for a seven-page website. Six years later I rebuilt it as static HTML between lunch and dinner. Before that sounds like a boast about the code, it is not — the code was the easy part, and most of the $9,000 was not wasted.

I have done that job, or something near enough to it, more times than I can count. What follows is one telling, with the numbers drawn from several — representative rather than a case study.

What the $9,000 actually bought

It is worth breaking this down, because "agency site cost $9,000" is the kind of line people use to argue that agencies are a rip-off, and that is not the argument here.

  • A visual identity. Someone chose the typeface, the colours and the grid, and they chose well enough that six years later it still looked deliberate. That was worth paying for.
  • Photography. A half-day shoot of the actual staff in the actual office, instead of stock photographs of handshakes. Worth paying for.
  • Copywriting. Somebody sat with the partners and worked out how to describe what they do without saying "solutions". Worth paying for, and the hardest part of any of it.
  • The build. A premium theme, configured. A page builder plugin. A form plugin. A slider plugin. This is the part I replaced.

Three of those four are still doing their job. The design, the photographs and the words all came across to the new site unchanged, because they were never the problem. The problem was the container they had been put into, and the six years of maintenance that container generated.

The design was fine. The words were fine. The container was the expensive part.
What actually needed replacing

The afternoon, hour by hour

Hour one: getting the content out

This is the genuinely tedious hour and nobody writes about it. Seven pages of text, thirty-one images, a staff list, and a set of PDFs of old newsletters linked from a page nobody had opened in years.

I pulled the rendered pages down with wget and worked from those rather than from the admin screens, because what the visitor sees is the specification. The page builder's own export was three thousand lines of nested shortcodes and was worse than useless.

Hour two: one file per page

Seven HTML files and one stylesheet. No templating language, no partials, no include mechanism — the header and footer are copied into each file, and when they change I change them in seven places with find-and-replace.

That sounds like a step backwards and I want to be honest about it rather than pretend it is elegant. It is a real cost. It is also, at seven pages, a cost of about ninety seconds a year, paid in exchange for never running a build.

services.html — the whole skeleton 
<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width,initial-scale=1">
  <title>Services — Hale &amp; Partners</title>
  <meta name="description" content="Accounts, tax and payroll for small businesses in Kent.">
  <link rel="stylesheet" href="/style.css">
</head>
<body>
  <!-- header: copied into all 7 files -->
  <main>
    <h1>Services</h1>
    <!-- the words, as paragraphs -->
  </main>
  <!-- footer: copied into all 7 files -->
</body>
</html>
No framework, no build, no partials. This site is built the same way, for the same reason.

Hour three: the images

The single biggest improvement of the day, and it had nothing to do with WordPress. The home page was loading a 4.2 MB photograph, at full camera resolution, scaled down in the browser to 1,400 pixels wide.

Resizing thirty-one images to the size they are actually displayed at, and exporting them as WebP with a JPEG fallback, took forty minutes and removed about nine tenths of the page weight. You can do this on a WordPress site too — plenty of plugins will, which is one more plugin — but nobody had.

Hour four: form, deploy, done

The contact form became nine lines of HTML pointing at a form service. The files went to a free static host. Two DNS records at the registrar, and about twenty minutes of waiting for a certificate.

What changed

Before After
Home page weight 4.9 MB 312 kB
Requests 84 9
Plugins 14 0
Monthly cost $31 $0
Things to update Core, theme, 14 plugins Nothing
Home page, cold cache. Representative figures; most of the weight was photographs, not WordPress.

Be careful with the first row. Most of that 4.6 MB was unoptimised images, and that was a mistake anyone could make on any platform. The rows that are actually about the platform are the last three.

Where the language model helped, and where it did not

I used one. It is worth being specific about what for, because "AI built my website" is doing a lot of load-bearing work in a lot of posts at the moment and most of it is nonsense.

It was good at: converting a wall of page-builder markup into clean semantic HTML, writing the repetitive parts of the stylesheet, generating the <picture> elements for thirty-one images without typos, and drafting alt text for photographs I described to it.

It was not good at: knowing which of the seven pages mattered. It happily reproduced the newsletter archive that nobody had opened in four years, because it had no way of knowing that, and I did — from the analytics, in about a minute.

It also produced markup that looked right and was subtly wrong twice: a heading level skipped from h1 to h3, and a form label that was not associated with its input. Both would have shipped if I had not read the output. Treat generated markup the way you would treat a junior's first pull request — usefully close, not finished.

The hard part

It was not the code, and it was not the images. It was a twenty-minute conversation about the admin login going away.

The office manager had never used it — they had asked the agency for changes, and the agency had done them. But knowing that a login existed felt like control, and taking it away felt like losing something, even though the thing being lost had never once been used.

That feeling is real and it is worth taking seriously rather than arguing with. What settled it was opening the services page in a text editor, finding the sentence about payroll, changing a word, and saving. They had expected code. It was a paragraph, with some angle brackets around it.

They have edited it several times since. The agency edited it twice in six years.

What I would tell you to copy

  • Start from the rendered page, not the admin. What the visitor sees is the specification; everything else is the platform talking to itself.
  • Check the analytics before you migrate a page. The fastest way to rebuild a seven-page site is to discover it is a four-page site.
  • Fix the images first if you only do one thing. It is usually most of the problem and it is platform-independent.
  • Have the login conversation early, and have it by showing rather than explaining.

And if it turns out the login was genuinely being used, by several people, several times a week — then you have found yourself in one of the cases where the CMS is earning its money, and you should keep it.