We rebuilt our own site today. The old roughworks.ca ran on WordPress with a heavyweight page builder. It loaded fine. Google indexed it. Nothing was broken. We replaced the whole front end with static HTML anyway.
The decision was about leverage, not necessity. For our own site — a portfolio that we control end-to-end and update on our own schedule — the simplest infrastructure that meets the requirement is the one we should ship. WordPress was carrying a lot of weight we weren't using.
What the new stack actually looks like
The public site is a pile of static HTML files served by our existing host. The pages were designed in an AI design tool and exported as HTML/CSS/JS — no React, no build step, no JavaScript framework. Every page is the markup that ships, full stop.
WordPress is still on the box. We didn't tear it out because removing a tool you've already paid for and configured rarely pays back. The admin interface runs at the usual path; we keep it around for the same reason we still own a passport even when we're not flying. It's there if we need it.
Deployment is fully automated. We edit files locally, push to a git repo, and a continuous-integration workflow rsyncs the changes to the host within a minute. We don't FTP, we don't SSH, we don't click "Update" in a CMS. Every change is a commit, and every commit is a deploy.
What it cost in actual hours
The rebuild took one workday — design through deploy. The honest breakdown:
- About two hours moving the existing content, themes, plugins, and database off the production server into a local Local-by-WP-Engine site for safekeeping. This was the slow part — production data is data, you don't take chances.
- About three hours setting up the deployment pipeline: SSH keys, GitHub Actions workflows, the rsync deploy action, secrets configuration. Most of this was one-time infrastructure that now works the same way for every client site we own.
- About thirty minutes designing the homepage and case study templates in our AI design environment, plus a follow-up hour iterating on the visual treatment.
- Roughly an hour wiring everything together: extracting the design bundle, renaming files to clean URLs, fixing internal cross-references, and pushing the first deploy.
- About two hours on a follow-up: switching from
.htmlURLs to directory-style clean URLs (/about/instead of/about.html), which required restructuring the file tree and rewriting internal links.
Total: about nine hours from "let's do this" to "live on the production domain." Most of the hours weren't the design or the code — they were the infrastructure and the moves between environments.
Things this trade lets us do that we couldn't before
Push fixes the same way we push code. A typo on the homepage used to mean opening a CMS, finding the editor, navigating to the right page block, fixing the text, clicking save, hoping the cache cleared. Now: edit a file in our editor, commit, push. The typo lives at a commit in git history. We can revert it. We can blame it. We can roll it forward.
Versioned visual design. The whole site exists as a small bundle of files. Every iteration of the design is a commit. We can go back and look at what the site looked like six months ago without spinning up a database backup.
Real performance. Pages render the instant the bytes arrive. There's no server-side processing between the request and the response — every URL is a file that already exists. For a portfolio site, this is what visitors should be getting.
Things we lost (deliberately)
The visual page builder. To change copy on the homepage, someone needs to know how to edit a file. For us — engineers who edit files all day — that trade is fine. For most of our clients, it isn't, and we still build their sites on systems that let non-technical authors write and publish. This pattern is not our default for client work; it's right for our own.
The CMS-managed blog. We replaced it with a markdown-driven blog that builds at deploy time. Posts are plain text files in a folder. They get rendered into the design template at deploy. The first post on this site is the one you're reading.
What's coming next
This rebuild is also the foundation for two systems we'll be writing about in the coming weeks. The first is an AI-assisted blog drafting workflow that takes a topic and a list of references, generates an outline, and produces a draft article for review. The second is a daily SEO audit that scores every post against our content silos and surfaces gaps and recommendations every morning. Both of these get to exist precisely because the site is now plain files in a git repo — they read and write the same files a human would.
Static isn't right for every site. It's particularly right for this one.
