Site builder, CMS or custom build: how we decide, and when we say no
A site builder covers a large share of real business websites. Our decision rule, written down, including the cases where the honest answer is that you do not need us.
Contents
Every project starts with the same question, and the honest answer is often "you do not need us". A site builder covers a large share of real business websites. Selling custom development into that share is how an agency loses a client twice: once on the invoice, and again on the rebuild.
This is our decision rule, written down so you can apply it before you write to us.
The three routes sell different things
They are not the cheap, the medium and the expensive version of one product.
- A site builder sells speed. A site in a day, template design, hosting and domain included. You pay with a subscription and with limits you do not set.
- An off-the-shelf CMS sells ready features. Catalogue, blog, accounts, thousands of plugins. You pay with updates, plugin conflicts and security work.
- A custom build sells control. What you need is what gets written. You pay with time and money.
So the question is never which technology is better. The question is what this site has to do that cannot be switched on.
When we say no
We turn work down when all of the following are true at the same time.
- The site talks about the company and shows a phone number. It does no work of its own.
- The catalogue is tens of items, not hundreds.
- Orders arrive by phone or by messenger.
- Nothing outside the site has to be connected: no warehouse, no accounting system, no CRM, no payment provider.
- One language is enough.
A team that hires a developer for that is buying nothing — and we say so in the first call, not after the estimate.
The ceiling of a builder shows up later, and it shows up slowly. Local payment providers publish plugins for common CMS platforms, and Payme documents its own, but on a builder you depend on whatever the platform already supports. Connections to a warehouse, an accounting system or a CRM are usually not possible at all. Multilingual support is often half-built. And the data, meaning customers, orders and content, lives inside the platform, which becomes the whole problem on the day you want to leave.
What leaving a builder costs
Nobody asks this at the start, because at the start a builder is cheap and fast. The bill arrives on the day there is a reason to leave, and the arithmetic is simple enough to do in advance.
Text and images move. You can export them by hand if you have to. Orders and the customer list depend on what the platform is willing to hand over, and that list is written by the platform, not by you. URLs almost always change, because the builder generated them by its own rules, and to a search engine the result looks like a new site rather than the same one.
That last part is the expensive one. A year of accumulated positions and inbound links is lost in the move unless every old address is redirected to its new one, and redirects are only possible if the old platform lets you set them. Check that before you start, not after.
The practical rule is to judge the decision on a three-year horizon rather than a one-year one. Over one year a builder almost always wins. Over three the answer depends on how much the site grew in the meantime.
What we do with a site that already runs on a CMS
We do not propose WordPress or a similar system for a new project. We build on our own stack, and we say that before the first estimate rather than after it.
A site that already exists is a different case. If yours runs on such a system today, we take it over, keep it running and write modules for it. That is support and maintenance and legacy modernisation, and both are real work rather than a polite way of proposing a rewrite.
Our stack and what it means for you
We write on Laravel with a modern frontend and PostgreSQL. The consequence for a client is short: the code and the data are yours, the site can be handed to another vendor, and no subscription can switch it off.
If your project has something that cannot be configured, such as a pricing rule of your own, your own logistics, a wholesale account area, or several languages and currencies, that is the case for custom web development. It is the only case we argue for.
Ask yourself three questions before you write to anyone. Does the site talk, or does it work? Is there anything outside the site it has to reach? What is left when the subscription ends? If all three point at a builder, use a builder and keep your money. If one of them does not, describe the task, and we will tell you what has to be built and what does not.