Last updated: 15 July 2026
When you order a website, someone makes a choice on your behalf that you rarely get to see: what it should be built on. React or WordPress. Custom code or a ready-made platform. A framework that is nine months old, or one that has been stable for ten years. You feel the consequences of that choice long after the site is delivered, but the choice itself happens quietly.
I think you should know a little about what lies underneath. Not to make the decision yourself, but to ask the right questions, and to understand why two quotes for what appears to be "the same website" can be completely different things.
It is not about which framework is coolest
Developers can argue endlessly about React versus Vue versus Svelte. For you running a business, that debate is largely irrelevant. The frontend, meaning the visible layer, is actually the layer with the least long-term risk. It can be replaced later without the whole house collapsing.
The choices that matter lie deeper, and they are not about what is new and exciting, but about three duller things: who can maintain it, how locked in you become, and how well it fits what you actually need.
Can anyone other than the builder maintain it?
This is the most important question, and the one most often overlooked. A solution built on widespread, well-documented technology can be taken over by another developer the day you need it. A solution built on an obscure framework that three people in the world know, or on a single developer's own inventions, ties you down.
People in the industry call it choosing technology with a living ecosystem: enough developers who know it, enough documentation, enough libraries. It sounds technical, but the consequence is simple. Can you change supplier without having to rebuild everything? With widespread technology: yes. With a dead end: no.
Does the choice lock you to one supplier?
Some solutions are built so they can only run in one place, with one supplier, on one platform you pay for monthly. Others are built so they can be moved. The difference is often called lock-in, and it is not always visible until you try to get out.
I am not saying platform solutions are bad. For many businesses a ready-made platform is exactly right, it is quick to get started with and requires little. But it should be a deliberate choice, not something you discover the day you want to move and are told "that is not possible". We have written about precisely this in the article on custom software or off-the-shelf, because these are two entirely legitimate routes, with entirely different consequences for ownership and freedom.
Does the technology fit what you actually need?
Here is the most common mistake: using a heavy tool for a light task, or the other way round. A simple company site with a handful of pages does not need the same machinery as a web shop with a thousand products and log-in. Building the first as if it were the second gives you complexity you pay for but never use, and that someone has to maintain for years.
We have written about the difference between a website and a web application, and the technology choice follows from precisely that distinction. The right tool for the job beats "the newest and most powerful" every time. Do not over-engineer a brochure; do not under-size a shop.
New is not the same as better
New frameworks appear all the time, and some developers cannot resist using the freshest one on your project. The problem is that a nine-month-old framework has not had time to prove that it is stable, that it will get security updates over time, or that there will be developers to hire in a couple of years.
Mature, boring technology is often the safest choice for a business, precisely because it is boring. It is tested, it is documented, and it will still be here in five years. There are exceptions where new technology gives a real advantage, but then it should be a reasoned decision, not because someone wanted to try something new at your expense.
The questions you can ask
You do not need to understand code to take this seriously. Four questions reveal most of it:
- Can another developer take this over if we change supplier? A good answer mentions widespread technology and documentation.
- Are we tied to one particular supplier or platform to run the solution? If yes, that is fine, but then you should know it in advance.
- Why this technology for our need? The answer should be about our task, not about what is popular right now.
- How mature and widespread is this? Newest is not safest.
A supplier who answers this calmly and concretely has thought the choice through. One who gets vague, or who answers with how cool something is, may have chosen technology for their own sake and not for yours.