Every project does not need the same solution. It needs the right one. Site builders and content management platforms give you speed, easy editing and no developer backlog. Custom code gives you control, performance headroom and freedom from platform ceilings. The mistake is picking based on fashion instead of trajectory.
The question is almost never “which is better”. It is “which is better for what this business will be doing in three years”, and that is a question about the business rather than the technology.
What a platform build does brilliantly
For marketing sites, content-driven pages and businesses that need to publish without engineers, a well-built platform site is the smart money. The client edits their own content, sections can be rearranged without a ticket, and the build ships in weeks rather than months.
We build most brand and marketing sites this way, engineered properly underneath, with performance budgets and a design system behind it, never a themed template with a logo dropped on top. That distinction is the whole game. A platform is a delivery mechanism, and it excuses nothing. The reason platform sites have a poor reputation for speed and consistency is rarely the platform. It is the accumulation of a page builder, a dozen plugins and images uploaded straight from a camera.
Platform builds also win on a factor nobody lists in a comparison table: how often the site actually changes. A site the marketing team updates weekly is worth far more than a technically superior site that nobody can touch without raising a request.
Where custom code earns its cost
The moment the site stops being a brochure and starts being a product, with bookings, member areas, dashboards, integrations or payment flows, the platform’s convenience becomes its ceiling. Plugins approximate your process instead of matching it, and every workaround adds fees, fragility or both.
That is when custom code pays for itself. The logic matches the business exactly, you own every line of it, and the cost stops being a monthly fee that rises with the number of records you hold.
The tell is usually a sentence somebody says in a meeting: “we just do that bit manually”. A member has to be approved by hand because the plugin’s rules do not quite fit. A price is adjusted after the order because the tax logic is not right for your case. Two systems are reconciled every Friday because neither will talk to the other. Each of those is a recurring cost, and each is the sort of thing custom software removes permanently.
The five questions that decide it
Most of the debate resolves once these are answered honestly.
1. Who edits it, and how often? If your team publishes weekly, editing experience outranks almost everything else. If the site changes twice a year, it is a much weaker argument.
2. Does the business logic fit the platform’s assumptions? Standard catalogue, standard checkout, standard contact form: a platform fits. Trade pricing tiers, approval workflows, multi-currency events, membership rules with exceptions: it usually does not.
3. What has to integrate? One or two well-supported connections are fine on a platform. A chain of systems that must stay in step, with your accounts package or your operations tool as the source of truth, tends to be where platform integrations become the fragile part.
4. What does scale look like for you? Scale is rarely traffic. It is usually complexity: more product variants, more user roles, more rules, more edge cases. Platforms handle volume well and complexity badly.
5. What happens if you want to leave? Ask what you can export, in what format, and what it would cost to move. If the answer is unclear, that is a price you are paying without seeing it.
Hybrids are usually the answer
It is rarely either/or. Many of the best systems are hybrids: a platform-driven marketing site where the team publishes freely, with custom-built engines behind the parts that are genuinely yours, such as the booking flow, the portal or the automation. The visitor never notices the seam, and neither stack is forced to do a job it is bad at.
A hybrid also sequences the spend sensibly. The marketing site can launch early on a platform while the custom part is being built properly, rather than holding the whole launch behind the hardest component.
The design decision that makes a hybrid work is the boundary. Decide early which system owns which data, and make one of them the source of truth for each thing. Hybrids fail when two systems both believe they own the customer record.
What each option really costs over five years
A fair comparison looks past the build fee.
A platform build has a lower entry cost and a recurring one: subscriptions, paid plugins, and the compounding cost of every workaround that is easier to accept than to solve. Those costs tend to scale with your success rather than staying flat.
A custom build has a higher entry cost and a different recurring one: hosting, maintenance, and someone available to change it. Its advantage is that complexity is absorbed rather than charged for, and its risk is that a badly documented custom system is harder to hand to somebody else than a standard one.
Neither is automatically cheaper. The relevant question is which cost curve matches where the business is going. If you want the ranges we work with, our website cost in Ireland piece sets them out, and the ecommerce version of this decision is in Shopify, WooCommerce or a custom build.
Ownership is the quiet deciding factor
The part that gets discussed least and matters most is what you own when the relationship with whoever built it ends.
Ownership means the code, the content, the data, the domain and the accounts are in your name, and that another competent developer could pick the project up. On a platform build it means knowing exactly what is portable and what is not. On a custom build it means insisting on documentation and a repository you control, because custom code you cannot hand over is a dependency with extra steps.
We hand over the keys on every project, whichever route it takes, and that is how our website development in Dublin work is scoped from the start. It is not generosity. It is what makes the decision reversible, and a reversible decision is a much easier one to make.
Function defines the tech
Tell us where the business is going and the right stack usually names itself. A publishing-led business with standard commerce wants an excellent platform build. A business whose process is its advantage wants that process in code it owns. Most businesses in between want a hybrid, with the boundary drawn deliberately rather than discovered later.
What none of them want is a decision made because a platform was trending, or because custom code sounded more serious.
