From Elementor to Custom Code: What Changed for the Client

What Elementor did well

I built with Elementor when I started the business, and it did the job. I no longer build with it, and not because it got worse, but because what I need to give a client changed.

It is worth starting from the fair side: Elementor solved a real problem. It made it possible to build a good looking site without writing a line of code, it shortened timelines dramatically, and it gave clients control over their content at a time when the alternative was calling a developer about every comma. It was the right choice then, and not as a compromise.

Where it broke down

The problems did not arrive all at once. They accumulated.

The plugin pile

A typical site ends up with dozens of plugins: one for forms, one for SEO, one for backups, one for security, one for galleries, one for speed that is meant to fix what the others broke. Each was written by someone different, updates on a different schedule, and can collide with its neighbour.

Load time

Every plugin brings its own code, and in most cases it loads on every page even when it is needed on one. The effect compounds, and it is felt most on mobile over a cellular connection, which is exactly where most visitors are.

Depending on other people's updates

This is the hardest point to explain to a client before it happens. An automatic plugin update can take down a site that worked perfectly yesterday, overnight, without anyone touching it. You find out in the morning, or worse, two days later.

The ceiling

On every site there is a moment when the client asks for something the tool was not built for. So you add a plugin, and if none exists, you add custom code inside the system, and that becomes a layer nobody wants to maintain. That is the ceiling, and it arrives sooner than you would think.

What changed on the tools side

I build in code today, but I do not type it line by line. I describe in words what the page needs to do, the code is written from that, and I read it, test it, and take responsibility for it. This is a way of working that did not exist two years ago.

And even so it is one paragraph in this post, deliberately. Everyone says they build with AI now, that sentence is already empty, and it drags the conversation down to price. What sets the work apart is not how the code was written, but that the sites actually went live, work, and hold up.

What changed for the client

This is the heart of it, and this is what is genuinely different:

• The site loads faster, and not by accident. There are no twenty plugins loading code nobody asked for. Only what this page needs is loaded.

• There is no plugin store. Nothing to update, nothing to collide, and no annual licence renewing across five different tools.

• No automatic update takes the site down overnight. What went live stays as it is until someone decides to change it.

• Full control over content. Text, images and lists are edited from an admin screen built for this site, not from a generic one trying to cover a million cases.

• No ceiling. An unusual request is work, not "impossible".

What did not change

This matters just as much, because this is where people get it wrong.

The tool does not do the discovery. It does not understand the business, it does not know the audience, it does not choose the message, and it certainly does not decide what is important enough to sit at the top of the page. The conversations, the understanding, the design and the ongoing support stayed exactly the same. What changed is how fast those decisions become a working site, and how good that site is in the end.

The one case where I would say stay on WordPress

There is one case, and it has nothing to do with budget or project size. It has to do with an asset that already exists.

If you have a large site that already works, an established business site or a store with hundreds of products, with strong organic ranking built over years, and someone maintaining it routinely, and what you need is to extend its capabilities rather than rebuild, then rebuilding is an unnecessary risk. You would be gambling years of accumulated ranking for a gain that is marginal against that risk.

That is the case. One.

Three things that sound like reasons and are not

"I have a store with hundreds of products"

Not a reason. Connecting a dedicated commerce system to a custom built site is straightforward work today, and it gives you a full catalogue with inventory, shipping and payments without dragging the whole pile along. Hundreds of products are not an argument against development, they are simply a requirement for the right architecture.

"A one page site does not justify development"

Also not a reason, and usually the reverse. A single page gains the most from fast loading and a sharp browsing experience, precisely because the visitor has nowhere else to go. Such a page can be built quickly, and often for less than a WordPress site, as long as it is not built around the assumption that it will be rewritten every week.

"My team already knows the interface"

This is the easiest one to disprove. An admin panel built for a specific site shows exactly that site's fields, rather than a generic screen trying to cover a million cases. It is more intuitive, more flexible and simpler than the WordPress admin, not less. Beyond that, switching interfaces is not a matter of luck: there is recorded training and written documentation, and getting comfortable takes one sitting.

The right question

The difference is not "good versus bad", and it is not "new versus old" either. The right question is what the site needs to do, how long it is meant to last, and who will maintain it. In most cases, when you start from a blank page, the answer no longer leads back to WordPress. The world moved on, and there is no reason to go backwards simply because that is how it used to be done.