Half the sites we build are WordPress and half are static. The split is not about what is trendy — it is about who edits the site and how often.

Choose WordPress when the client writes

If someone in the office publishes news, changes prices weekly, adds job posts or writes a blog, WordPress is still the honest answer. The editor is familiar, the plugins exist, and a non-technical person can work without calling you.

That convenience has a cost. You inherit updates, plugin conflicts, a database to back up and a login page that bots will find. Every WordPress site we maintain has a maintenance line item, and it is not padding — it is what keeps it from being defaced in eighteen months.

Choose a static site when the content is stable

A brochure site with twelve services and a contact page does not need a database. Neither does a portfolio, a landing page or documentation. If the content changes a few times a year, a static build is faster, cheaper to host and has no attack surface at all — there is no admin panel to log into, so there is nothing to brute-force.

Our own site is built this way: 64 pages generated from content fragments and JSON by a Python script, deployed as plain files. There is no runtime, so there is nothing to patch.

The question that decides it

Ask who will change the content, and how often. If the answer is "our team, every week", that is WordPress. If it is "we'll send you changes when something changes", a static site is cheaper to run for years and you are not paying for a CMS nobody opens.

What about editing comfort?

The gap has narrowed. Modern static setups can put a Git-based editor in front of the content, so a non-technical person writes in a familiar form and the site rebuilds itself. That works well for a blog. It works less well for a shop, where inventory, orders and payments genuinely need a server.

Where people go wrong

They pick WordPress for a five-page brochure site and spend the next three years paying for updates and cleanups. Or they pick a static site for a business that publishes daily, and the staff end up emailing a Word document to a developer every morning, which is worse than any CMS.

Decide by the writing, not by the technology.