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.