Agencies redesign other people's websites for a living and rarely touch their own. Ours ran on WordPress and the Divi page builder for the better part of a decade — the exact stack we spend our days migrating clients off of. In June 2026 we moved it: 155 pages, onto the flat-file mini-CMS we built in-house, with full URL parity so nothing a client or a search engine had already indexed broke.
This is not a client story. It's what happened when we had to eat our own advice at our own scale — a decade of blog posts, service pages, and city/market pages, not a four-page nonprofit site.
What we were actually running
WordPress plus Divi is a real, capable stack — we still build on it for clients who want that flexibility. But ten years of posts, plugins, and page-builder markup accumulate weight that has nothing to do with the content itself: a database to query on every request, a plugin stack to patch, and HTML that Divi generates in layers of nested <div>s no human ever wrote by hand.
None of that is visible to a visitor scrolling the page. All of it is visible to Google, and to anyone waiting for the page to finish loading.
What actually moved to a new architecture
The mini-CMS is deliberately boring: clean HTML and CSS, no database, no PHP framework sitting between a request and the response, no plugin whose next update might break something unrelated. Every page still carries its own [HEADER] / [HERO] / [CONTENT] / [FOOTER] structure, so a change to the shared header or footer is one edit, not 155 of them — the same problem WordPress solves with a database, solved instead with a build step.
Every one of the 155 pages kept its existing URL. A decade of backlinks and indexed pages moved with zero 301 chains and zero re-crawl cliff.
The number we can actually stand behind
We are not going to hand you a single before/after PageSpeed table for the whole site the way we would for a client — we didn't keep the old WordPress install running long enough to re-score it fairly, and quoting a number we can't reproduce is exactly the kind of case study we'd criticize someone else for publishing. What we can show you is the current, real, repeatable number for the homepage — median of three live PageSpeed Insights runs, mobile and desktop, run the same day this was written:
| Metric | Mobile | Desktop |
|---|---|---|
| Performance | 70 | 66–99 (noisy) |
| Accessibility | 96 | 96 |
| SEO | 100 | 100 |
| Largest Contentful Paint | 2.9s | 1.1s |
Good, not perfect — and the desktop spread is real, not a typo. A site this size still has pages we're actively tuning; one of our own service pages is currently carrying too much image weight, and it's on our own list to fix, the same way we'd flag it for a client. A flat-file architecture makes a page fast by default. It doesn't make heavy images light on its own — that's still a job someone has to do, and we'd rather tell you that than pretend otherwise.
What actually changed, in plain terms
- No database, no plugins. Nothing to patch, nothing to break on an auto-update we didn't ask for.
- Every page still editable by chat through the same AI Site Manager we build for clients — no admin dashboard, no page-builder UI to relearn.
- Full URL parity across all 155 pages — nothing re-indexed from zero.
- One shared header and footer for the whole site, edited once and baked into every page automatically.
We build this for clients because we believe in it. Now our own site runs on it too — warts, ongoing tuning, and all.