Build And Ship
Every few years someone declares WordPress dead. It keeps running a quarter of the internet while they do it.
WordPress is a content management system. For a business website its real advantage is not features, it is exit: the content belongs to you, the hosting is portable, and almost every developer and marketer you might hire already knows it. That combination is rarer than the feature comparisons suggest.
The best tool is often the one the next person already knows.
I build brand sites on it, including this one. I do not build applications on it, and the line between those two things is the whole decision.
What is WordPress actually good at?
Publishing. Pages, posts, categories, media, revisions, scheduled content, multiple authors with different permissions. That sounds unglamorous until you try to build it yourself and discover you have spent three weeks rebuilding a content editor.
It is also good at being handed over. A business owner can log in and change their own hours, add a service, publish an article. A site nobody can update without a developer is not an asset, it is a liability with nice typography.
When is WordPress the wrong tool?
When the thing you are building is an application rather than a site. If users have accounts, if there is state, if data relationships matter, you want a real database and a proper front end framework. Bending WordPress into an app is possible and it is nearly always a mistake you pay for later.
The test I use: does this page mostly display content, or does it mostly do something? Display goes on WordPress. Doing goes on Next.js and Supabase.
That is why both live on my stack page rather than one replacing the other. They are not competitors. They answer different questions.
Use a content system for content. Use an application framework for applications. Most bad builds start by ignoring that sentence.
The plugin problem
Every plugin is three things at once: a feature, a dependency, and a security surface. People count the first and ignore the other two.
A site with forty plugins is a site with forty codebases you did not write, updating on forty different schedules, any one of which can break your checkout or quietly stop being maintained. The abandoned plugin is the dangerous one, because nothing appears wrong until a WordPress core update arrives and something stops working.
My rule is simple. A plugin has to earn its place by doing something I genuinely cannot do without it, and I would rather write twenty lines of code than install a plugin to avoid writing twenty lines of code.
How WordPress sits in the rest of the stack
WordPress runs the brand sites. Elementor handles the layout and the reusable header, footer and archive templates. Yoast manages titles, meta descriptions, sitemaps and schema output. Those three are effectively one decision, because choosing WordPress means choosing what you will build pages with and what will handle your technical SEO.
Everything transactional sits elsewhere. Stripe takes the money, Resend sends the transactional mail, n8n moves records between systems. WordPress publishes. It does not need to be the whole business.
What breaks?
Page speed, and it is almost always self inflicted. WordPress is not slow. A theme loading four font families, a page builder emitting nested wrappers, six plugins each queueing their own stylesheet, and uncompressed hero images is slow. The platform gets blamed for choices made on top of it.
The second failure is the update nobody tests. Auto updating everything on a live site is how a Tuesday morning becomes an outage. Staging exists for a reason, and the reason is that plugin authors do not test against your specific combination of plugins.
The third is content debt. Five years of posts, half of them thin, none of them pruned, all of them indexed. A content system makes publishing easy, which means it also makes accumulating rubbish easy. Audit it or it audits you.
Software that is easy to add to is software that needs a deliberate habit of subtraction.
Common questions
Is WordPress still good for business websites?
Yes, for content led sites. It handles publishing, permissions and handover well, the hosting is portable, and the hiring pool already knows it. It is a poor choice for applications with accounts, state and complex data relationships.
Is WordPress bad for SEO?
No. WordPress is neutral and its structure is search friendly out of the box. Poor SEO on a WordPress site comes from thin content, bloated themes and unmanaged plugins, not from the platform.
How many plugins is too many?
There is no fixed number, but every plugin is a dependency and a security surface as well as a feature. The useful question is whether each one does something you genuinely could not do otherwise.
WordPress or a website builder like Squarespace?
A builder is faster to start and simpler to maintain. WordPress gives you ownership of the content, portability of hosting, and no ceiling on customisation. Choose the builder for simple brochure sites and WordPress when the site has to grow.
Why is my WordPress site slow?
Almost always the layers on top: multiple font families, a page builder emitting heavy markup, several plugins each loading their own assets, and uncompressed images. Audit those before blaming the platform.
Pick the platform your successor can inherit. You are not going to run this forever, and pretending otherwise is how businesses get trapped inside their own websites.
