Website builder or custom code: which to choose

The "builder or code" argument is usually held the wrong way round. Both sides compare the cost of development and miss that with a builder the price is stretched over time, while with code it is gathered at the start. That is what the answer depends on, and for different tasks it comes out differently.

Where a builder genuinely wins

A builder is somebody else's platform on which you assemble a bot or a site out of ready blocks, usually with a mouse. For sites that means Wix, Squarespace, Tilda and platforms like them; for bots, separate builders put together on the same principle. You pay monthly, and the platform takes on the servers, the updates and keeping things running. The barrier to entry is close to zero: a simple bot with a menu and enquiry intake really can be put together in an evening without a developer.

That is a fair advantage and there is no point talking it down. If the task is to find out whether there is any demand, a builder beats code outright. A hypothesis that did not pan out cost twelve dollars and one evening rather than five hundred and a week of waiting. The same goes for one-off things such as a bot for the duration of an event, sign-ups for a single intake, or a storefront that runs until the end of the season.

Wix and Squarespace deserve a separate word, because they are what people ask about most. For a landing page, a services site or a small storefront they do exactly what they promise: the page is assembled quickly, it looks decent, and it can be edited without a developer. Their limits are the ones every builder has, and they begin at your own logic, your own integrations and moving all of it to another platform. The subscription runs monthly and rarely makes it into the launch budget, although over three years it adds up to a sum comparable with development.

The three ceilings a builder runs into

A builder does have a ceiling, and it is always hit in the same place: when the logic stops being linear. While the scenario looks like a sequence of questions, answers and an enquiry, everything goes well. As soon as a condition appears along the lines of "if the subscription is active and the city is such-and-such, show a different list, otherwise offer payment and afterwards return one step back", the fight with the platform begins. It can be assembled, but what you assemble will be fragile, and nobody except its author will make sense of it.

The second ceiling is integrations. Builders connect popular services, but popular for them, not for you. Your accounting system, an industry-specific service or an in-house database are not on the list. Sometimes a generic webhook saves the day, but complex exchanges are hard to build through one and there is almost nothing to debug them with.

The third ceiling, the most unpleasant one, is about data and dependency. Your customer database sits with the platform. There is usually an export, but what exports is the data, not the logic: scenarios, settings and relationships have to be rebuilt from scratch in the new place. So the decision to leave keeps being postponed while the subscription fee keeps ticking. Add to that the fact that the platform can change its pricing, remove a feature you rely on or shut down, and there is nothing you can do about it.

What your own code gives you and what it costs

Code has the opposite set of properties. It is more expensive and slower at the start, and after that there are almost no limits: any logic, any integrations, your own interface, your own rules. Monthly you pay for a server rather than for the right to use your own product. The source code belongs to you, and that is not an abstraction: with it the project can be handed to another developer, and without it, it cannot be handed over at all.

Code also has real downsides, and they are usually left unsaid. Development has to be waited for. A small text change cannot be made yourself unless an admin panel was built for it. Somebody has to maintain the server. Quality depends entirely on the contractor, because badly written code is worse than any builder: repairing it costs more than rewriting it.

How to choose for your own task

The practical rule turns out to be fairly simple. If you are testing an idea, the deadline is tight and the budget is small, start with a builder and do not listen to developers, ourselves included. If the product works, brings in money, and you are running into the platform's limits, it is time to move to code. And if the task was never a standard one, or involves money, other people's data and external systems, a builder will not do and the attempt will only cost you time.

The middle route and the moment to move

There is also a middle route that rarely gets mentioned: leave in the builder what works well there and move only the bottleneck into code. Enquiry intake and payment stay on the platform, while the calculation, the export or the integration with your system live as a separate service that the platform calls by webhook. The architecture is not the prettiest, but nothing has to be rewritten all at once.

If a move does become necessary, it is cheaper to do it sooner. The longer a product lives on a platform, the more undocumented settings accumulate in it, and the more time goes on reconstructing the logic from screenshots. A convenient moment to move is when a year of subscription fees starts approaching the cost of development. At that point it stops being a matter of taste and becomes arithmetic.