WordPress or custom code: which should you choose?

A studio that writes its own code has an obvious interest in telling you WordPress is bad. We will try to skip that part. WordPress runs an enormous share of the internet because in a lot of cases it genuinely does the job. The question is not which one is better, it is which one is better for what you are building, and what it will have cost you three years from now rather than in the first month.

When WordPress is the right choice

There are situations where we would recommend WordPress ourselves, and there is no sense in hiding that.

If you write a lot of content and publish several times a week, WordPress was built for precisely that. Text editing, categories, authors and archives are all built in, and they work without anyone writing a line of code. If you need something standard that thousands of sites already have, there is probably a plugin that solves it today rather than in two weeks.

The same holds if the budget is very small and the site is simple. A tidy WordPress site that works beats an expensive project that never gets finished.

Where the real cost hides

The price of building a WordPress site is usually lower. The cost of owning one is not, and that only becomes visible later. We broke down what the price is actually made of in how much a website costs.

• Plugins with an annual licence. Serious plugins for forms, SEO, e-commerce and security are billed every year. Five of those is a standing cost nobody mentions in the first quote.
• Maintenance. The core, the theme and the plugins update constantly. If they are not updated, the site becomes vulnerable. If they are updated without checking, something occasionally falls apart.
• Conflicts between plugins. Two plugins that work beautifully on their own can pick a fight with each other. Tracking down the cause is work nobody planned for.
• Hosting. WordPress asks more of the server than a static site does, so cheap hosting quickly turns into the bottleneck.

Security: not because it is bad, but because it is everywhere

WordPress is not insecure by nature. It gets attacked because it is the most widespread, which makes an automated attack on a known vulnerability worth the effort. When a flaw in a popular plugin is published, bots start hunting for it across the whole internet within hours.

The practical consequence: a WordPress site demands discipline. Regular updates, a limited number of plugins, strong passwords, backups. All of that is doable, but it is work somebody has to keep doing, and it is a line item to agree on up front rather than discover the morning the site refuses to open.

Speed can be measured

A ready-made theme arrives carrying code for a hundred situations, three of which you need. The other ninety-seven travel with you on every single page load. On top of that come the plugins, each injecting its own slice of code, and a simple page ends up pulling a megabyte and a half before anything at all is visible.

When the code is written for the project, the page carries only what the page needs. The one you are reading right now paints its main content on a phone in about a second: that is not a claim you have to take on faith, put our URL into PageSpeed Insights and check it yourself.

Whether that difference matters depends on the business. For a blog with three posts a month, probably not. For a shop or a booking system, where every visitor lost is an order lost, it does. Speed is also one of the reasons a site does not show up on Google.

When custom code makes sense

Custom code pays off when what you need is not standard. At Navy Blue two brands share the same fleet and the same calendar, so a booking made on one site has to take the slot on the other. There is no plugin for that. At Zov Divljine the search has to understand that “štap” and “stap” mean the same thing: Croatian words carry diacritics, and Croatian shoppers routinely type without them, so an off-the-shelf search would return zero results for the word they actually typed.

The second reason is long-term maintenance. When the code is yours, a change is just a change. When it belongs to someone else, a change is a hunt for the one spot where the theme author anticipated it, and if they did not, it gets solved with a workaround that falls apart at the first update.

The third path that rarely gets mentioned

The choice is not just WordPress or building everything from scratch. For smaller sites there is the static web: the pages are generated in advance and served as finished files from a CDN. There is no database that can go down, no plugins that need updating, no attack surface. Hosting is close to free and the speed is the best available.

For bigger projects with a catalogue, payments and user accounts you go with a proper system, in our case usually Next.js and PostgreSQL. The content can still be edited through an interface, it is just that the interface is built for your content rather than being generic. What a project like that involves in scope and price is set out in how much a web shop costs.

The conclusion, without hedging: if you write a lot, have a small budget and need standard things, WordPress is a sensible decision. If speed, security or unusual logic affect your revenue, a ready-made platform will cost you more over a few years than it ever saved you. How we approach a build is on the web development page. And if you already have a WordPress site and are weighing up what to do with it, there is also redesign or a new website.