Web development changed within two years. A clean, modern site is no longer difficult. AI tools produce layout, copy and colour in minutes, and they do it well. The result is visible in the market: pages look more and more like one another.
That is not a problem. It is the new starting point. But it moves the difference somewhere else, below the surface, into software architecture.
Appearance became a commodity
Whatever is easy to produce stops setting anyone apart. Appearance has joined that category. Ten firms in the same sector will show you ten similar mockups, and none of them will be bad.
We deliberately keep a light, minimalist style. Not for want of ideas. A spare interface loads faster, reads on a phone, survives a change of content and does not need a redesign every two years. Restraint is a technical decision, not an aesthetic preference.
Fast code breaks differently
Today's tools write code that works. That is true, and it is useful. But they write code that works now, for the scenario described to them, with no knowledge of what sits around it.
The symptoms are specific, and we see them in the systems we take over:
- A query that runs 200 times on one page instead of once, and only shows itself when real data arrives.
- The same logic written in three places, two of which were forgotten in the last update.
- A database with no migrations, where nobody knows what schema the server is on.
- Code no developer can explain, because no developer thought it through.
None of this stops a site from being delivered. All of it stops a site from evolving.
What architecture means in practice
Maintainable code is not a philosophy. It is a set of measurable decisions taken before the first line is written.
Where the business logic lives, so that it changes in one place. How the database is described, so that every change is reversible. Which library goes in and which does not, because every dependency is a promise to maintain it for years. How one customer's data is kept apart from another's. What happens when an external service does not answer.
None of these decisions show up in a screenshot. They determine whether the project costs you money or returns it in year two.
Expertise transfers, output does not
We use AI daily. It is an excellent tool in the hands of somebody who knows what they are asking for and recognises when the answer is wrong. Judgement is the scarce part, not output.
That is why we work with few, stable tools and know them deeply. We contribute to OpenCart with pull requests and in the project's discussions. When something breaks in production, we are not working out how the system behaves. We know.
Three questions before you commission a project
Whoever you end up choosing, ask:
- What happens when I want a change in six months? If the answer assumes parts will be rewritten, the project was not designed.
- Who else can work on this? Code only one person understands is a risk, not an asset.
- Where does the data live and how do I get a backup? If there is no clear answer, there is no backup.
Appearance became cheap, and that is good for everyone. The question left is whether what you are building will still work when it has to change.