Short answer
WordPress stopped being our default in 2019 because five recurring costs added up past the upfront speed it bought us: plugin sprawl that degraded performance and turned security patching into a quarterly fire drill, page builder lock-in that made future redesigns painful, a performance ceiling on shared hosting against Core Web Vitals, custom features that turned a CMS into a quasi-application, and a security surface that made them the most attacked sites we maintained. What replaced it was not a single stack but fit-for-purpose choices: headless Next.js with a CMS like Sanity or DatoCMS for content-first sites, a custom Laravel or Node backend with React or Vue and PostgreSQL for applications with real business logic, and a stripped-down WordPress with a strict no-plugins policy for genuinely simple brochure sites. The default has not reverted since. We start with the problem the client is trying to solve and pick the stack that fits.
For our first two years we built on WordPress by default. The reasoning was simple: clients had heard of it, the ecosystem was huge, and onboarding a new junior developer to a WordPress codebase took a week instead of a month. In 2019 we stopped recommending it for new builds. This is what changed.
What WordPress was good at
WordPress is genuinely good for a narrow set of cases. A small business that needs a brochure site they can edit themselves. A blog where the writer is non-technical and wants Gutenberg, not a Markdown file in a repo. A site where the budget is small and the requirements will not evolve much over the first three years.
For those briefs WordPress remains a defensible choice. We still maintain a few WordPress installs for long-time clients who fit that profile, and we do not plan to migrate them off the platform just because their stack is unfashionable.
What WordPress was quietly costing us
The problems showed up when projects outgrew the brochure shape. By 2019 we had repeatedly walked clients through a familiar set of pains:
- Plugin sprawl. A standard install we delivered cleanly would, eighteen months later, accumulate twenty third-party plugins added by various marketers and freelancers. Performance degraded. Security patching became a quarterly fire drill.
- Page builder lock-in. Clients who fell in love with Elementor or Divi could not be migrated easily. The page builder's HTML structure was specific to the builder, and lifting out clean content for a future redesign was painful.
- Performance ceiling. Even with caching layers and a competent host, WordPress on shared hosting struggled to hit the Core Web Vitals thresholds Google was starting to score sites on.
- Custom feature drag. Every time a client wanted something WordPress did not do natively, we built a plugin or a custom post type. By the second or third custom feature, we were maintaining a quasi-application inside a CMS that did not want to be one.
- Security surface area. WordPress sites were, simply, the most attacked sites we maintained. Brute-force login attempts were constant. The xmlrpc endpoint was a target. Vulnerable plugins were routinely a source of incidents.
Each of these was manageable in isolation. Together they consumed enough maintenance time that we questioned whether the upfront speed of using WordPress was actually a win across the life of a project.
What we moved to
The shift was not radical. We did not adopt one stack and stop everything else. We moved toward fit-for-purpose decisions:
- For content-first sites with real editorial flow, we adopted a headless approach. The frontend was usually Next.js. The content lived in a CMS designed for the role, often Sanity or DatoCMS. Content teams kept a friendly editing surface; developers kept a clean, fast, secure frontend.
- For web applications with real business logic, we went straight to a custom stack. Laravel or Node on the backend, React or Vue on the frontend, PostgreSQL for data. Building these as applications from day one was cheaper across the life of the project than starting in WordPress and migrating later.
- For small brochure sites where the client truly wanted to edit text and replace images, we offered a stripped-down WordPress install with a curated theme and a strict no-plugins policy. We were honest that we were using it as a glorified CMS, and that anything more complex should be scoped as a separate project.
What this looked like commercially
The shift cost us short-term revenue. WordPress projects were cheaper for clients to commission, so quoting custom builds meant some clients walked away. The clients who stayed were the ones with real product ambitions, and their projects were more interesting to work on.
The studio's revenue per project went up. So did the time we spent in scoping conversations. We made our peace with both.
A note on WordPress in 2026 and beyond
WordPress is not dead. It still powers a meaningful share of the web, including pages of household-name companies that have no reason to migrate. Newer block-based theming is more capable than the page-builder era. Headless WordPress is a legitimate option for content-led sites.
But our default has not reverted. When a new client walks in with a real product idea, we do not start the conversation with WordPress. We start it with the problem they are trying to solve, and we pick the stack that fits.
If you are running a WordPress site that has outgrown the platform, that is a normal next step, not a crisis. We do migrations regularly and they are usually less painful than the team expects.
Questions · 04
Frequently asked questions
Does this mean we should migrate our WordPress site?
Not on principle. WordPress remains a defensible choice for a small business brochure site the owner edits themselves, a blog written by a non-technical writer who wants Gutenberg rather than Markdown in a repo, and sites where the budget is small and requirements will not evolve much over the first three years. We still maintain WordPress installs for long-time clients who fit that profile and have no plans to move them just because the stack is unfashionable.
How do I know our site has outgrown WordPress?
The usual signs are twenty third-party plugins accumulated over eighteen months by various marketers and freelancers, security patching that has become a quarterly fire drill, and a second or third custom feature built as a plugin or custom post type. At that point you are maintaining a quasi-application inside a CMS that does not want to be one, and each problem compounds the others.
What did dropping WordPress cost the studio commercially?
Short-term revenue. WordPress projects were cheaper for clients to commission, so quoting custom builds meant some clients walked away, and the time we spent in scoping conversations went up. Revenue per project also went up, and the clients who stayed were the ones with real product ambitions, so we made our peace with both.
How painful is a migration off WordPress?
Usually less painful than the team expects. We do migrations regularly, and outgrowing the platform is a normal next step rather than a crisis. The part that takes the most work is typically page builder content, since Elementor and Divi produce HTML structures specific to the builder and lifting out clean content for a redesign is not automatic.
