The cost of a website does not end with the quote
When a business starts a web project, attention naturally goes to the quote, meaning the cost of building the site, the number of pages included and the price of maintenance.
These questions matter, yet they often miss the main one, which is how much the site will cost to run over the next five years.
A website keeps changing after the day it goes live. It will need new features, bug fixes and fresh content, along with adjustments to changes in browsers, payment systems and regulations. That is when the technical choices made at the start of the project really begin to show their effects.
Two businesses can sell the same products, have a comparable catalogue and receive similar traffic. Yet one will spend a few hundred euros a year maintaining its site, while the other will regularly need a developer for changes that should be simple. The difference does not always come down to the skill of the provider. It often stems from the way the project was conceived from the outset.
More powerful hosting does not fix a poor architecture
When a site slows down, many businesses change hosting provider, on the reasoning that a more powerful server will make the site faster.
That is sometimes true. In many other cases, it amounts to fitting a bigger engine to a car whose brakes are worn.
Consider a concrete example, an online shop with two hundred products in which a single product is edited. On some architectures, that one edit triggers a rebuild of the entire catalogue, every category page and the home page. Each change sets off a cascade of processing that keeps the server busy for no reason. Pages are recalculated although their content has not changed, the database is queried constantly, and resource consumption rises without bringing the visitor any value.
A more modern architecture, by contrast, will generally recalculate only what actually needs it. The edited product page is regenerated, while the other pages keep being served from a cache as long as they have not changed. Terms such as cache, CDN or Incremental Static Regeneration (ISR) all come down to a very simple idea, which is to avoid redoing work that has already been done.
The benefit goes beyond performance. The server works less, running costs fall and the site can absorb more traffic without an immediate increase in hosting resources.
Website performance is a business matter
The performance of a website is often reduced to a technical concern, although its consequences show up directly in revenue.
A page that takes several seconds to display increases the risk that a visitor leaves the site before even discovering your offer. When that visitor comes from a Google Ads campaign or a social media ad, the slowness also means that part of your marketing budget disappears without producing any result.
The same logic applies to e-commerce. A slow checkout, an unresponsive on-site search or a product page that takes too long to load all create points of friction that gradually lower the conversion rate.
Performance therefore concerns far more than developers. It directly affects your customer acquisition cost, your organic search rankings and your ability to turn a visitor into a buyer.
Good architecture is about removing unnecessary work
The purpose of a web architecture is to simplify how the site works, rather than to stack technologies on top of one another.
In practice, this means not querying a database when the information is already available, not recalculating a page that has not changed, and making sure that a new product does not force a rebuild of the entire catalogue.
These optimisations may seem highly technical, yet each of them follows an economic logic. Every operation avoided means processor time saved, fewer resources consumed and a site that is easier to maintain.
This way of designing a project also changes how it evolves. Instead of piling up workarounds as new needs appear, the aim is to build an architecture able to support the company's growth without calling its foundations into question every six months.
When plugins accumulate
It is hard to blame a business owner for using plugins, since their promise is precisely to add a feature quickly without starting from scratch. A search engine, a booking system, an accounting connector or advanced shipping management can each be added in a few clicks.
The difficulty rarely appears at launch. It arrives a year or two later, once the site has grown with the business. Needs have multiplied, and so have extensions, and each change becomes a little more delicate than the last. One update blocks another, a plugin is abandoned by its developer, and a feature that should be simple requires hours of testing to make sure nothing else has broken.
This phenomenon has a name, technical debt. Unlike financial debt, it never appears on an invoice. It shows itself when tasks that should take an hour end up taking four, when a sales campaign is delayed because a seemingly minor change has become risky, or when switching provider becomes almost impossible because the site depends on a chain of extensions built by different vendors.
Plugins remain excellent tools when they meet a specific need. The difficulty lies in building the project's entire architecture around them.
Choosing a technology starts with the business model
Comparisons between Shopify, WooCommerce, Medusa and Payload CMS often give the impression that one platform is objectively better than the others. In practice, the question is poorly framed.
A small artisan shop with thirty products does not face the same constraints as a B2B e-commerce site, a marketplace or a catalogue of several thousand items. Yet many businesses still choose their technology the way they would choose a smartphone, looking at the tool's popularity rather than at the project's actual needs.
The role of an architecture is to support a business model, whatever the current trends may be.
Two examples illustrate the point. A small shop that publishes a few new products a month and receives around fifty visitors a day probably has no reason to deploy infrastructure designed to absorb hundreds of thousands of daily visits. Conversely, a company that plans to add new product ranges regularly, sell to professional buyers, manage customer-specific pricing or connect several business systems will quickly reach the limits of a solution designed above all to be easy to use.
In both cases, the technology can be excellent. What changes is the context in which it is used.
Good architecture also protects your ability to evolve
Architecture tends to be associated with performance or stability, although its impact is often more visible elsewhere, in the speed at which a business can develop its activity.
Suppose you want to launch a new offer, change your checkout flow or create a specific experience for your business customers. If each change requires several days of development because the site relies on dependencies that are hard to maintain, the cost is no longer measured only in development hours. It is measured in missed opportunities.
An architecture designed to evolve, on the other hand, makes experimentation easier. A new feature can be developed without calling the whole project into question, a marketing campaign can go live quickly, and an integration with a new business tool becomes a reasonable project instead of several weeks of work.
This flexibility is often what separates a website that supports a company's growth from one that gradually ends up slowing it down.
Technology serves the business
Developers enjoy talking about frameworks, caching, CDNs and databases. No business owner, however, buys a website in order to use Next.js, Payload CMS or Medusa. What they buy is a tool able to support their business.
The choice of a technology therefore only makes sense when it answers a business question.
A caching system is worth having because it serves pages faster, limits server load and avoids paying for resources that create no value, whatever the modernity of its approach.
A headless architecture becomes relevant when it makes it easier to integrate an ERP, a PIM, several sales channels or business rules that would otherwise have been difficult to implement. Its technical sophistication alone does not justify it.
In other words, technical decisions are only worthwhile when they produce a concrete result for the business, whether saving time, reducing costs, improving conversions or making future changes easier.
At Nualt
We never begin a project by asking which CMS or framework to use. We begin by understanding how the business works.
That means looking at how the catalogue changes, how often the content is updated, whether the site will need to support several languages, several markets or specific pricing rules, and which features are likely to appear in two or three years.
These questions may seem far removed from development, yet they determine most of the technical choices that follow.
We sometimes recommend an off-the-shelf solution when the context suits it. In other cases, a more flexible architecture is the natural choice. Our role is to build a site that stays aligned with the company's objectives over time, whichever technology that requires.
In the end, a good architecture is rarely noticed, since its value is measured by the number of problems it prevents before they ever arise.
What businesses ask us before starting a web project
Answers to the questions we hear most often on this topic.
Why does a website become more expensive over time?
The cost of a site does not depend on hosting alone. Functional changes, maintenance, updates, technical dependencies and performance all weigh heavily on its running costs. A well-designed architecture keeps these expenses down over the long term.
Does more expensive hosting always make a website faster?
No. If the site performs unnecessary processing or relies on a poorly optimised architecture, a more powerful server will often only mask the problem. It is usually more worthwhile to optimise how the site works before increasing hosting resources.
Do plugins always slow a website down?
Not necessarily. A well-built plugin can be perfectly suited to a specific need. Difficulties arise when their number grows and the site depends on several extensions interacting with one another. Maintenance then becomes more complex and performance can gradually deteriorate.
How do you choose the right technology for a website?
The choice depends above all on the project. Traffic volume, catalogue size, commercial goals, business constraints and growth prospects often matter more than the popularity of a framework or CMS. A relevant technology is first and foremost one that fits the project.
