WordPress or a custom website? An honest comparison
A large share of the web runs on WordPress, and that is no accident — in plenty of situations it is a perfectly sensible choice. The trouble starts when it is picked automatically, without asking whether it fits this particular project. What follows is a comparison without tribal arguments: what you pay for, and where exactly the line runs.
Author: Bartosz Gonta
1. What you are really paying for with WordPress
The strengths are real: an enormous plugin ecosystem, an admin panel many people already know, thousands of ready-made themes, and no difficulty finding someone to take it over later.
The cost is real too, just spread over time. A typical business site on a theme loads plenty of files it will never use, because the theme has to serve every case from a restaurant to a law firm. Then there is the update cycle: the core, the theme and a dozen plugins, each one a separate attack surface and a separate reason the site might fall over overnight.
2. When WordPress is the right call
There is no point arguing against it where it works well:
- a blog or magazine with many authors and an editorial workflow,
- a shop that needs standard integrations already available as plugins,
- a project on a very tight budget where an off-the-shelf theme does the job,
- a team that already knows the panel and does not want to relearn anything.
The common thread: a lot of content managed by several people, and few unusual features.
3. When it starts costing more than it saves
The line runs where the project stops resembling a template. A custom configurator, your own booking logic, an integration nobody has wrapped in a plugin, a demanding animation layer — that is where you start gluing extensions to one another.
That is usually where performance problems show up too. Not because WordPress cannot be made fast — it can. But it is made fast by stacking caching plugins on top of something that loads too much, instead of simply loading less.
A practical rule: if the plugin list runs past a dozen entries and half of them exist to fix what the other half does, the theme has run out — you are now paying to work around it.
4. What a site built from scratch gives you
A site built in Next.js and generated statically is a set of finished HTML files pushed to a CDN. No database query on every visit, no PHP layer to maintain, no login panel sitting there as an attack surface.
The practical consequences are easy to measure:
- Performance: Only what is actually on the page gets loaded — no dead theme code. That feeds straight into Core Web Vitals and your position in Google.
- Security: Static files have nothing to execute. A whole class of plugin vulnerability problems disappears.
- Maintenance: There is no weekly update after which you have to check whether the site still looks the same.
- Freedom: Layout, animation and features do not have to fit inside whatever the theme author anticipated.
5. The main objection: “who will edit it later?”
That is the most common and most reasonable worry about custom sites. The answer is not “nobody” — content in such a project can live in content files or in a headless CMS that gives you a panel much like WordPress's, without dragging the rest of it along.
The one thing worth settling at the start rather than after launch: what exactly you want to change yourself, and how often. A brochure site updated twice a year and a portal with a new post every week are two different decisions.
Not sure which side of that line your project sits on? Describe briefly what it needs to do and I'll send a recommendation along with a free quote within 48 hours.
Have a project in mind? Describe it briefly — I reply personally, usually within 24 hours.
