Ask three people and you get three confident, incompatible answers. The people who sell templates say that custom code is a luxury from another era. The people who write code say that templates are heavy and all alike. There is some truth inside both claims, and neither of them answers the question the buyer actually has.
The question that matters is not "which of the two technologies is better". It is this: how much work will this site create once it is built, who is going to do that work, and what happens if that person looks away for two years?
Answer that one, and the technology usually decides itself.
There are three paths here, not two
A template is a bought design: a ready-made layout, almost always for WordPress, that you install and fill with the company’s words and pictures. It is what most company websites in Portugal are. In Portuguese we keep the English word, because it is established jargon and translating it would only confuse.
A block platform is the third case, the one usually left out of the argument: a service where you drag sections around a page, inside your browser. There are no files and there is no installation. There is also no way out: what you build there stays there, and on the day you want to move house you have no files to take with you.
Custom code is a site written deliberately for that one business. It does not mean complicated, and it does not mean expensive by definition. It means the site contains only what that site needs.
A good template beats a badly built custom site
This section is here because it is true, not out of politeness.
A template is the right choice when the site has to be live quickly and the design is not the business’s argument. A company that sells through personal relationships, and only needs a credible address on the internet, gains nothing from six weeks of design.
It is the right choice when the content changes often and it is the team that changes it. Whoever moves the opening hours in August, and moves them again in September, needs a panel that anyone can learn in an afternoon. A mature content management system does that better than something built on purpose and then explained.
It is the right choice when the site needs features that already exist, solved: bookings with payment, a catalogue with stock, subscriptions, invoicing. Rebuilding all of that from scratch is expensive, and the worse part is that it is expensive in order to arrive at a less tested result.
And it is the right choice when nobody is going to look at the site for three years and it still has to work. A system with automatic updates degrades more gracefully than a hand-built site made by someone who has since stopped answering the phone.
A good template, well filled in, is better than a badly built custom site. That is not a rhetorical concession: it is the correct order of things.
Weight, speed, and one calendar fewer
That is what custom code buys. Three concrete things, and none of them is "beautiful design", which is possible on either side.
Weight. A template is built to serve many different businesses, so it carries with it everything that any one of them might one day need. The theme’s stylesheets and code load even on the pages that do not use half of their functions.
Every plugin you install then adds its own files to every page on the site, including the pages that never use it: the contact form plugin loads on the "About us" page as well, and that page has no form on it at all. This is not a manufacturing defect: it is the price of a generic part.
You do not have to take our word for it, or anyone else’s. Look at your own site:
- Open it on a computer and press F12, which opens the browser’s developer tools.
- Choose the network tab.
- Reload the page.
There it is: the list of every file the page asked for, and how much each one weighs. A custom site asks for few; a site with many plugins asks for many.
Speed. Weight is the cause, speed is the consequence, and the consequence is measured rather than argued about. What that means on a client’s phone, on a mobile network, has numbers of its own and an article of its own.
Nothing to update on a calendar. A site made of a core, a theme and plugins has a permanent calendar of security updates, and every update is a small bet that nothing breaks. A site made of static files has no such calendar, because it has none of those parts.
It still needs someone to change the words when reality changes, and no technology solves that. But it does not need maintenance just to stay the same.
It does not buy immunity or independence
It is worth being clear about this too.
Custom code does not buy immunity. A badly built custom site is slow all the same, and being slow is easier than it sounds: four photographs uploaded at their original size are enough.
It does not buy easy editing by default. If you want to change the words yourself, that is a project decision and it has to be written into the quote. It does not arrive as a bonus with the choice of technology.
And it does not buy independence from whoever built it, unless the code is handed over to you and lives in accounts of your own. That is a separate question, and it is the most important of the three.
Three questions decide this, and none is about technology
- How many times a month will somebody touch the site? If the answer is "often" and the person touching it is not technical, they need a content management panel, wherever it comes from.
- Is this site a shop window or a tool? A shop window has to open fast and tell the truth in fifteen seconds. A tool has to do the work (book, sell, schedule), and there what matters is that the mechanism has been tested.
- Who is next to touch this, and will they understand what is in there? It is the question almost nobody asks, and it is the one that gets paid for later.
We write custom code, and we say what that costs
The reason is not purism. The kind of client we work with, the people who live on reputation and word of mouth, needs few pages, very well made, that open fast and tell the truth. In that format, the cost of a generic part is paid in full and almost none of it is used.
What that costs we have already written down elsewhere, when we explained why we do not build thirty-page websites: less surface, fewer automatic mechanisms, and a decision about each thing instead of a default. We are not the right studio for everyone, and we say so before we quote, not after.
If this choice is on your table and you want an opinion from people who lose nothing by telling you that the template is the right answer, book a 15 minute call.
Sources
No page weight average is cited in this article, and that is an editorial decision: the numbers that circulate on this subject cannot be verified by the people reading them. Everything stated here can be confirmed by the reader on their own site, using the network tab of the browser’s developer tools.