A website is no longer static. It is a living organism!
Why a website used to be hard to change, what changed in how they are built and the theory behind it (the law of continuing change, continuous delivery), explained for non-technical readers.
For years, a website was the monster nobody wanted to touch. It was built, it was live, and every change took time, several stages and reprogramming everything by hand. Today the home page of this site says the opposite: a website is no longer static. It is a living organism, changing at the pace of your ideas.
This article explains why. First in everyday language, then with the engineering and the theory behind it, for anyone who wants to check that this is more than a sales line.
Why a website was a monster
The tools existed. There were already repositories, backups, histories and version control. What weighed was the cost of each change, measured in time.
- Everything was reprogrammed by hand. Every change, however small, was written line by line by someone who knew that code.
- Every change went through several stages. Design, develop, test, fix, test again. Each stage had its wait, and often its own person.
- Changing a little cost almost as much as changing a lot. The stages were the same for swapping a sentence or for creating a page. It is like calling a building crew to change a light bulb.
With that arithmetic, the sensible decision was to batch requests and postpone. The site stayed as it was, further and further from the business.
The loop that never closed
When a change really was needed, a sequence began that anyone who built websites the old way knows well. Think the idea through. Understand the complications and the technologies it needs. Test. Develop. Test again. Fix. Develop again. Redesign. Then the loop started over.
Each turn took a dedicated team and days or weeks of waiting. Software engineering has a name for this: the cost of change. Barry Boehm showed in the 1980s that a change costs more the later it is made. For a long time that was accepted as a law of nature, and projects tried to decide everything at the start so nothing had to be touched afterwards.
What changed, in four parts
Today the road is short: you ask, it gets done, it is live. It rests on four parts. The first three already existed and are still the safety net. The fourth is the one that changed the arithmetic.
1. A history of everything. The site lives in a version control system (Git). Every change is saved as a step, with a date and a description. It works like the history of a shared document, for the whole site: you can see what changed and go back to any point.
2. The site is built before it is published. The pages are generated in one go, as finished files, and only then replace the ones that are live. If any page fails to build, publishing stops and the site visitors see is not touched. It is the difference between rehearsing and improvising on stage.
3. Publishing is automatic. The same steps, in the same order, every time, with nobody sending files by hand. Engineers call it continuous delivery. On this site a change takes between half an hour and an hour to go live, with no one involved.
4. AI does the execution, a person decides. AI reads the whole site and writes the code for the change in minutes. That was the work that needed a team dedicated to every line. What changes, and whether it turned out well, is still decided by me and the client.
It was the fourth part that took the manual work out of each change. The cost of changing stopped depending on a team’s time, and came within reach of a small business.
The theory: this is not a fashion
In 1980, Meir Lehman published his laws of software evolution. The first, the law of continuing change, says that a system used in the real world must be continually adapted, or it becomes progressively less useful. The world around it changes, and a system that stands still falls behind even though nothing in it broke. A website left alone is the perfect example: the prices, the services and the photographs of the business changed, and the site did not.
The second idea comes from the research on software teams gathered in the book Accelerate (Forsgren, Humble and Kim, 2018). Teams that publish small, frequent changes also have fewer failures and recover from them faster. Speed and stability go together, contrary to what intuition says.
The reason can be understood without being an engineer. A small change has few things that can go wrong, and when one does, you know at once where. A huge change, made once a year, packs a hundred risks into a single night.
This site is the proof
This site went live on 29 September 2026. In its first six days it was published 70 times. Each publication is a real change: wording tuned, a gallery fixed, a new section, lighter fonts.
The best example is the sentence in the title. On 4 October a section about this subject went onto the home page. That same evening I saw it live, removed a block that was one too many and rewrote the closing line until it became the one that is there now. On the Work page, a band of images started at the top with every project and ended at the bottom of the page, smaller, showing only the work that has no page of its own. All in one evening.
The old way, each of those turns would have been a request, a wait and an invoice.
What “alive” does not mean
- It does not mean unstable. Every change is recorded, looked at on a computer and on a phone before it goes live, and can be undone.
- It does not mean change for its own sake. The site changes when the business needs it or when there is a better idea.
- It does not mean everything is instant. Good photographs, good writing and a well-considered decision still take the time they take. What stopped taking long is the execution.
What this means for a business
A business changes every week: a price, a new service, a campaign, a better photograph. Sometimes it changes more: a new theme, a rebrand, a page or a feature that is now needed, another language. The ideas are endless. A static site forces a choice between paying for each change as a project and leaving it out of date. A living site keeps up with all of them.
And because the code is yours and lives in a repository in your account, that freedom does not depend on me: you can carry on with me, with your team or with your own AI tool.
If you have a site nobody dares to touch, talk to me.
Further reading
- Barry Boehm, Software Engineering Economics (1981): the cost of changing a system over time.
- Meir Lehman, “Programs, Life Cycles, and Laws of Software Evolution”, Proceedings of the IEEE (1980): the law of continuing change.
- Jez Humble and David Farley, Continuous Delivery (2010): automatic publishing, in small steps.
- Nicole Forsgren, Jez Humble and Gene Kim, Accelerate (2018): how publishing frequency and stability relate.
