WordPress or a hand-coded static site? How to actually choose

Most agencies answer this before you have finished asking. They build WordPress sites, so you need a WordPress site. Or they build static sites, so WordPress is bloated and slow.

Both answers are sometimes right. The decision comes down to a small number of questions about how your business actually operates — not about which technology is better.

The question that settles it most often

How often will the content change, and who will change it?

If the answer is “a few times a year, and we would ask you anyway”, a CMS is overhead you will pay for every month and use twice. If the answer is “weekly, and we want to do it ourselves without asking anyone”, you need an editor screen, and that means WordPress or something like it.

Almost everything else follows from that.

What a static site actually gets you

A hand-coded static site is HTML and CSS served exactly as written. There is no database, no plugin stack, and nothing that executes on the server when someone visits.

• It is fast in a way that is hard to argue with. There is no query to run and no template to assemble — the page is already the page.
• There is nothing to patch. No plugin updates, no PHP version anxiety, no 3am email about a vulnerability in something you have never heard of.
• The attack surface is close to zero. No login screen, no database, nothing to inject into.
• Hosting is cheap and effectively unbreakable. Static files survive traffic spikes that would take a small WordPress instance offline.

The trade is real: content changes come through whoever built it. For a business that updates rarely, that is a fair deal — often a better one than paying for a CMS nobody logs into.

We built AniMall this way. It is a pet shop and grooming salon: the services do not change monthly, the audience arrives on a phone on mobile data, and the owner did not need a login — she needed bookings arriving in WhatsApp. A CMS would have added a maintenance obligation and improved nothing a customer sees.

DP Investments is the same call for a different reason. A property management company publishes rarely, and the site exists to answer a small set of owner objections in a fixed order. Static suits it.

What WordPress actually gets you

WordPress earns its overhead when content is the product, or when someone other than the developer needs to publish without asking.

• An editor screen your team can use without touching code.
• Structure that scales — categories, taxonomies, search, and templates that render a hundred items as easily as three.
• An ecosystem for the genuinely hard problems: e-commerce, memberships, multilingual content, bookings with real availability.
• Portability. Your content is in a standard, exportable format that any WordPress developer can pick up.

We built ToolNixy on WordPress for exactly these reasons — a catalogue of more than fifty tools that grows every week, each needing its own URL and template. Hand-coding that would mean writing a new page by hand every time, which is untenable by the twentieth one.

The part that gets WordPress a bad reputation

Slow WordPress sites are usually not WordPress being slow. They are a page builder, twenty plugins and a bought theme, all loading on every page.

A page builder adds a rendering layer plus a large amount of CSS and JavaScript to every request, whether a page uses those features or not. Stack a slider, a form plugin, a cookie banner and an analytics suite on top and you have a homepage that ships several megabytes to do the job of a brochure.

Built on a custom theme with plugins added deliberately, WordPress is perfectly capable of being fast. The technology is rarely the problem — the assembly is.

A short decision guide

Choose static when: content changes a few times a year; the site is essentially a well-argued brochure; speed on mobile connections matters; you would rather not own a maintenance schedule.

Choose WordPress when: someone non-technical needs to publish regularly; you have a growing catalogue, blog or resource library; you need e-commerce, memberships or bookings; several people need different levels of access.

It is closer than it looks when: you want a blog “eventually”. Eventually often never arrives, and a CMS maintained for a blog nobody writes is pure cost. It is usually cheaper to build static now and add a blog when there is something to publish.

The questions to ask whoever is quoting

• Why this approach for this business, in terms of how we operate rather than what you prefer to build?
• If we choose a CMS, is it a custom theme or a page builder — and what does each page actually load?
• Who owns the domain, the hosting account and the source files? (The answer should be you.)
• What is the ongoing maintenance obligation, and who carries it?
• What happens if we want to move to another developer in two years?

How we decide

We do not have a default stack. Some of our builds are hand-written HTML with no JavaScript at all; others are WordPress on a fully custom theme. The decision comes from the brief — how often you publish, who publishes, and what the site has to do — rather than from what we would rather write.

Our web development service covers both, and if the project also needs a domain and hosting configured, we handle that in the same engagement rather than leaving you to coordinate it.

Not sure which way your project falls? Describe how your business publishes and we will tell you honestly which one fits — including when it is the cheaper option.