WordPress or lean custom? The costs nobody prices in

People ask me whether they should build on WordPress or go with something custom, and they usually expect a verdict. I don't have one. I've built and maintained custom WordPress functionality, including form add-ons and lead-data capture workflows, and I also run sites that are plain PHP with no framework at all. Both are the right answer somewhere.

What I do have is a set of questions that make the choice obvious for a given business. Most of them are about costs that don't show up in the build quote.

What WordPress does well

WordPress earns its popularity. For a lot of businesses it's the sensible default, and I'd say so without hesitation.

• Non-developers can edit it. Marketing can publish a page, fix a typo or add a landing page without opening a ticket. That independence is worth a lot.
• The ecosystem is enormous. Forms, SEO, caching, page builders, e-commerce, memberships. Tools like Gravity Forms, Rank Math and Elementor Pro cover a huge range of needs without custom code.
• Speed to launch. A capable team can get a solid site live quickly because most of the pieces already exist.
• Hiring is easy. When your developer moves on, finding another person who knows WordPress is not hard.

For content-heavy marketing sites with regular publishing, multiple editors and a need to move quickly, those strengths are hard to beat.

What WordPress costs over time

The costs are real, and they compound quietly.

• Plugin sprawl. Each plugin solves one problem and adds code, database queries, assets and a dependency on someone else's release schedule. Sites tend to accumulate plugins and rarely shed them.
• Updates never stop. Core, themes and plugins all update. Somebody has to apply those updates, test that nothing broke, and roll back when something does. Skipping updates isn't an option either.
• Security surface. Every plugin is code running on your server. More plugins means more places for a vulnerability to appear, and WordPress is a common target precisely because it's everywhere.
• Performance tuning. A stock WordPress site with a page builder and a dozen plugins is rarely fast by default. Getting it fast means caching (LiteSpeed Cache or similar), a CDN, image handling, and discipline about what loads on each page.
• Hosting. WordPress needs PHP, a database and enough server resources to handle uncached requests. Cheap shared hosting and a heavy site are a bad pairing.

None of these are reasons to avoid WordPress. They're reasons to budget for it honestly. If you've read inspect the system before trusting the symptom, you'll recognize these as the same places slow sites and broken forms usually come from.

What lean custom and static do well

A lean custom site, meaning plain server-side code or static files with no CMS, trades flexibility for simplicity.

• Speed. Very little runs on each request. Pages can be fast without a stack of caching layers.
• Tiny attack surface. No plugin directory, no admin panel exposed to the internet, far fewer moving parts to patch.
• Low maintenance. If nothing is changing, there's very little that needs updating.
• Full control. Every line does something you chose. Nothing is loading because a plugin decided it should.

The catch is significant: changing it usually requires a developer. If the marketing team wants a new landing page on a Tuesday afternoon, a custom site turns that into a request, a wait and a deploy. For some businesses that's fine. For others it's a daily bottleneck.

Total cost of ownership questions

Here are the questions I ask before recommending either direction:

1. Who edits the site, and how often? If non-technical people publish weekly, lean toward a CMS. If content changes a few times a year, a custom or static site is easy to live with.
2. Who maintains it after launch? Name the person. If the answer is "nobody," a WordPress site will drift out of date and become a liability.
3. What does the site need to do? Brochure content, lead forms, e-commerce, gated content and integrations with a CRM each push the answer differently.
4. How many plugins would this realistically need? If the list is long, count each one as a recurring cost in updates, risk and speed.
5. What happens when it breaks? Who gets called, how fast, and what does downtime cost the business?
6. What does hosting look like in year three, not week one? Growth in traffic and content affects the two stacks very differently.
7. Can you leave? How hard would it be to move this site to a different host or developer later?

The answers tend to point clearly one way. When they don't, WordPress with a short, disciplined plugin list is usually the safer compromise.

My own site as an example

This site, hectorherrera.me, is plain PHP. No framework, no build step, no trackers, self-hosted on a server I run.

That fits because of the answers to the questions above. I'm the only editor. I'm a developer, so changing it is easy for me. It doesn't need forms feeding a CRM, e-commerce or a team of publishers. I care a lot about speed and a small attack surface, and I don't want third-party scripts on it. For a personal site, it's the simplest architecture that does the job.

It would be the wrong choice for a lot of businesses. A legal marketing site with several people publishing, frequent landing pages for campaigns, complex forms and attribution feeding an intake system would suffer on a stack like mine. Every change would wait on a developer. That's a real business cost, even if the site is faster.

Common mistakes

• Choosing custom for prestige. A custom build nobody on staff can edit is a trap, not an asset.
• Choosing WordPress and never budgeting maintenance. The build is the cheap part. Ownership is the expensive part.
• Stacking page builder, theme framework and many plugins on cheap hosting, then blaming WordPress for being slow.
• Rebuilding to fix what configuration would fix. Many "we need a new site" conversations are really "we need fewer plugins and proper caching" conversations.

The short version

Choose the simplest architecture that will still scale for the people who actually have to use it. For many businesses that's WordPress, kept lean. For some, it's a small custom site that barely needs touching. The wrong answer is the one picked without pricing in who edits it, who maintains it and what it costs to own. That's the systems view from every web problem eventually becomes a systems problem applied to one decision.