I started building websites with WordPress in 2011, and at the time it genuinely felt like exactly what the web needed. You could build a professional website without creating an entire content management system from scratch, hand it over to a client, and give them a reasonably simple way to manage their own content. There was a theme for almost every kind of business, a plugin for nearly every missing feature, and a huge community around the platform. For someone building websites for small businesses, it made perfect sense, so I stuck with it.
Over the next 15 years, I built a lot of WordPress websites. I worked with custom themes, pre-built themes, page builders, Elementor, endless custom CSS, hosting panels, databases, caching systems, security tools, backup systems and all the other little pieces that eventually become second nature when you have lived with a platform for that long. You develop a strange kind of instinct for WordPress after a while. You can often guess which plugin is causing a problem before disabling anything, you know which updates make you slightly nervous, and you accumulate a whole library of fixes for problems that probably should not exist in the first place.
I also want to be clear that WordPress served me incredibly well. It helped me build a career and eventually became a big part of how Outrun Studio delivered websites to clients. For years, I never really questioned whether WordPress was the right choice. It was mature, flexible, familiar and could be adapted to almost anything we needed. If a client wanted a new feature, there was usually a plugin for it, and if there wasn't, there was almost always another way to make it happen. That flexibility was one of its greatest strengths.
Flexibility turned into baggage
At some point, though, that same flexibility started to feel more like baggage. There was no dramatic moment where WordPress suddenly became a bad product, and there certainly was not one catastrophic project that made me swear it off forever. It was much slower than that. A plugin update would break some spacing. A page builder update would cause a widget to stop behaving properly. A simple business website would gradually accumulate plugins for forms, SEO, redirects, image optimization, security, backups and caching, and then we would install another optimization plugin to improve the performance of the website after all those previous plugins had made it heavier.
Eventually I started looking at some of these sites and wondering why they had become so complicated in the first place. Most of the websites we build at Outrun are not complex applications. They are business websites. A contractor needs to explain what they do, show examples of their work and generate leads. A dental office needs to list its services, locations and staff while making it easy for patients to get in touch. A law firm needs to explain the types of cases it handles and give potential clients a clear way to contact them. These websites are extremely important to the businesses behind them, but from a technical standpoint, most of them are not particularly complicated.
That raised a pretty simple question for me. Does a five or ten page business website really need a database running behind every page request, a publicly accessible admin login, a visual page builder and a collection of plugins all doing different things in the background? In most cases, I do not think it does. What the client actually needs is a website that looks good, loads quickly, ranks well, generates business and does not randomly break because one plugin updated before another.
The maintenance piled up
For a long time I simply accepted the maintenance as part of working with WordPress. You keep the core updated, monitor the plugins, check PHP compatibility, make sure the backups are working, keep an eye on security and periodically deal with whatever strange issue appears next. None of those things are particularly outrageous when you look at them individually, but when you are managing dozens of websites, all those tiny responsibilities start to pile up. A few minutes here and twenty minutes there gradually becomes a significant amount of time spent maintaining the platform itself.
Anyone who has managed WordPress sites for long enough knows the feeling of updating a site and then immediately noticing that something looks wrong. Maybe the spacing changed, a widget vanished, a plugin stopped working with the page builder or something simply looks slightly different for no obvious reason. Then comes the usual process of clearing caches, checking the browser console, looking through error logs, disabling plugins one by one and eventually finding the culprit. You fix it, move on, and a few weeks later you end up doing almost the exact same thing somewhere else.
That is when I started realizing that too much of our time was being spent solving problems related to WordPress rather than improving the actual websites. Our clients do not hire Outrun because they care about PHP versions, plugin compatibility or JavaScript conflicts. They care about whether their website looks professional, whether people can find them on Google and whether the site helps bring in business. The technical work behind the scenes is obviously important, but when maintaining the platform starts competing with the actual goals of the website, something feels backwards.
Speed meant undoing the stack
Performance was another reason I started questioning the whole setup. You can absolutely build an extremely fast WordPress website, and I have done it many times, but getting there often feels like fighting against all the layers you have added along the way. You start with WordPress, install a theme, add a page builder, install the plugins the site needs and suddenly you have a large amount of CSS, JavaScript, fonts and third-party code being loaded. Then you begin optimizing everything. You add caching, defer scripts, minify files, lazy-load images, configure a CDN and try to prevent plugins from loading assets on pages where they are not needed.
You can eventually get excellent performance, but the process started feeling increasingly absurd to me. We were creating complexity and then spending time correcting the consequences of that complexity. Instead of asking how to make a heavy WordPress stack faster, I started asking why the website needed to be heavy in the first place.
These screenshots are Google PageSpeed Insights on live sites we rebuilt off WordPress.
Fewer things on the public internet
Security follows a similar pattern. WordPress itself is not inherently insecure, and after working with it for 15 years I am not going to pretend otherwise. The issue is that every extra moving part creates another thing that has to be maintained. You have WordPress itself, PHP, a database, themes, plugins and user accounts, all of which need to stay current and secure. For a large application or a complex publishing platform, that infrastructure might make perfect sense. For a simple local business website, it started to feel like a lot of machinery just to serve some text, images and a contact form.
When we began moving toward a static-first approach, a lot of those concerns simply disappeared. Most pages can be generated as HTML, CSS and optimized images, which means there is no production database involved every time someone loads a page and no WordPress login sitting there waiting for automated login attempts. There are simply fewer things that can go wrong, fewer things to update and fewer systems exposed to the public internet.
A simpler way to edit
One of the biggest surprises in all of this was that moving away from WordPress actually improved the client experience. For years, one of the strongest arguments for WordPress was that clients could manage their own websites, and technically that is true. In reality, I have watched plenty of clients log into a WordPress dashboard and immediately feel lost. They see pages, posts, theme settings, plugin notices, SEO options, update warnings and banners asking them to upgrade to some Pro version of something they do not even understand.
Then they click "Edit with Elementor" because all they want to do is change their business hours, and suddenly they are dealing with containers, responsive controls, margins, padding and dozens of design options they never asked for. For a developer, that level of control can be useful. For a business owner who just wants to change a sentence or update a phone number, it is unnecessary and intimidating.
Using a system like Sanity changed the way I thought about content management. Instead of giving clients access to the entire machinery of the website, we can give them access to the parts they actually need to manage. That might be services, employees, locations, articles, testimonials or photos depending on the business. They can change the content without touching the layout, and the design remains consistent. A client can fix a typo without worrying that they might accidentally drag half the homepage out of place.
There is something slightly ironic about leaving the world's most popular content management system and discovering that content management becomes easier. Separating the content from the design has made the whole experience cleaner for us and, more importantly, much simpler for clients.
Google sees the finished page
SEO was one area where I was initially cautious about moving away from WordPress because Outrun does a lot of SEO work. After years of working inside WordPress, it is easy to mentally associate SEO with plugins like Yoast or Rank Math. You install the plugin, fill out some fields, try to make the little indicator turn green and it starts to feel like the plugin itself is responsible for SEO. In reality, Google does not care whether WordPress generated a page. It sees the final website.
What actually matters is the structure of the page, the content, internal links, load times, metadata, structured data, semantic HTML and the overall quality of the experience. Having direct control over the final output has actually made a lot of our SEO work cleaner because we are no longer trying to convince a theme or page builder to produce the structure we want. We can simply build it properly from the beginning.
Ownership still had to matter
At the same time, I did not want to leave WordPress only to move clients into some closed proprietary website builder. That would solve one problem by creating another. I do not like the idea of clients effectively renting their own websites from a platform where everything disappears the moment they stop paying or where moving to another provider means starting over. If we were going to leave an open-source platform, ownership still had to matter.
Our current approach keeps the website code versioned and the content exportable, with the different pieces of the system separated from one another. If a client ever decides they no longer want to work with Outrun, another competent developer should be able to take over. We are building websites for clients, not trying to trap them inside our own ecosystem.
We also did not move away from WordPress because I suddenly became obsessed with the latest JavaScript framework. The web development world is very good at replacing old complexity with fashionable new complexity and congratulating itself for the innovation. That was not what I wanted. I wanted less.
That is one of the reasons Astro made sense for us. It allows us to build modern websites without turning every small business website into a giant JavaScript application. The CMS manages content, the hosting platform handles deployment and hosting, and Astro builds the website. Each piece has a very specific job and, for the most part, they leave each other alone.
The websites got quiet
Once we started working this way, I noticed something I had not really expected. The websites became quiet. There are fewer update warnings, fewer plugin conflicts, fewer maintenance surprises and far fewer moments where something suddenly stops working because two parts of the system no longer agree with each other. The websites mostly just sit there and work.
That might sound boring, but after 15 years of maintaining WordPress sites, boring is actually pretty wonderful. It means more of our time can go into improving the things clients actually care about, such as content, landing pages, SEO, conversion rates, calls to action, design and the overall performance of the website as a business tool. I would much rather spend an afternoon figuring out how to generate more leads for a client than trying to understand why a plugin suddenly has an issue with PHP 8.3.
WordPress is not the villain
So no, I do not think WordPress is bad. Pretending that after building a career with it for 15 years would be dishonest. There are excellent developers building excellent websites with WordPress, and there are projects where it still makes perfect sense. Large publishing operations are an obvious example. WooCommerce can still be the right choice for certain businesses, and some complex editorial workflows benefit from everything WordPress provides.
I also would not tell a client with a healthy, profitable and well-maintained WordPress website to rebuild everything simply because our preferred stack has changed. Technology should serve the business, not the other way around. If the website is working, performing well and doing its job, rebuilding it just to use a different technology would be difficult to justify.
When we are starting from scratch, however, the decision is very different than it was a decade ago. The same is true when a client comes to us with an aging WordPress site that has become slow, difficult to manage and buried under years of plugins and technical debt. In those cases, I am much less interested in adding another layer of fixes on top of everything that is already there. Sometimes the better answer is simply to remove the complexity.
WordPress taught me an enormous amount about building websites, working with clients and understanding how technical debt accumulates over time. It also taught me something about flexibility. Having endless options sounds great until you realize that every option eventually becomes another thing someone has to manage.
In 2011, WordPress was absolutely the right tool for me. It carried me through a huge part of my career and became an important part of how Outrun Studio was built. I am not bitter about moving away from it, and I am certainly not pretending it was a mistake.
We have simply reached a point where most of the websites we build no longer need everything WordPress brings with it.
And for us, that feels like progress.
If that sounds like the site you are stuck with, the WordPress migration page is the practical version of this post. Or tell us what the current site is doing.