A system you can’t evolve isn’t yours

A new system almost always arrives with a good demo. It works, it solves what was asked and the team starts using it. The problems show up six months later, when the company needs to change something: a new field, another provider, a different rule. And the answer is that it has to be requested, quoted and waited for.

At that point you discover something that wasn’t in the contract: the system works, but the company doesn’t control it.

What’s expensive isn’t building a system. What’s expensive is not being able to change it afterwards.

A prediction worth reading carefully

On 29 September 2026, Gartner published a striking prediction: by 2028, 70% of enterprises will abandon agentic AI built by vendor forward-deployed engineering, trapped by rising costs and unable to evolve it on their own.

According to DIGIT’s coverage, analyst Mukul Saha sums it up: success starts by structuring the engagement properly, from scope and incentives to governance, ownership and exit.

The prediction is about AI agents, but the pattern is old. When only the person who built a system understands it, every change goes through that person. And AI doesn’t correct that pattern: it accelerates it. If building is faster, what nobody else understands also piles up faster.

Depending on someone isn’t the problem

I build systems for other companies and support them afterwards. It would be dishonest to say that depending on someone who knows a system inside out is bad: that’s exactly what makes changes quick and well done.

The problem is something else: that only that person can understand it. The difference lies in how it’s built from day one. An evolvable system has some properties you can check:

• The data lives somewhere the company controls, with a model that can be understood without reading the code.
• External pieces can be swapped without rewriting the rest: the AI provider, the email provider, the payment provider.
• What changes often is configuration, not code.
• There are automated tests that warn if a change breaks something.
• Decisions are written down, with their reasons.

None of this shows in a demo. All of it shows the first day something needs changing.

Three decisions that pay off later

Here are three systems where those properties were decided at the start, when there was nothing to change yet.

Rocio.com: the database is in charge

Rocio.com has an AI assistant over an archive going back to 1992. The underlying decision was that the database is the single source of truth, for the AI too. The vector index is disposable: it’s rebuilt entirely from the database. The provider sits behind an internal contract, so changing it doesn’t touch the rest of the system. No provider identifier lives inside the editorial content.

If a better or cheaper model appears tomorrow, switching is a contained job, not a migration.

Guía en Sevilla: content as data

At Guía en Sevilla, a tour guide’s website I rebuilt, pages live in a central registry and reuse templates by page type. Adding a page means adding an entry, not creating a new file. Internal links point to identifiers: if a route changes, they resolve on their own. And tests check that every published route resolves in its language, that images exist and that redirects arrive in a single hop.

The site is in three languages. Without those decisions, every change would have had to be made three times, and some would have been forgotten.

Zentia: branding is configuration

Zentia runs several real-estate agencies on a single core. Each agency’s colours, logo, typography and copy live in data. A new agency doesn’t need a new deployment: it’s created or cloned from a super-admin panel.

What will change the most (the agencies and their brands) is exactly what doesn’t require touching code.

What to ask before commissioning a system

It doesn’t matter whether a vendor, an in-house team or I build it. These questions help you know whether what’s going to be built will be yours:

1. Where does the data live, and who has direct access to it?
2. If the AI, email or payment provider changes, what has to be touched?
3. What can be changed without programming: copy, rules, prices, brands?
4. Which automated tests protect what matters?
5. Where are decisions written down, and why were they made?
6. If another technical person joins tomorrow, how long will it take them to understand it?

If the answers are vague, the system may work very well today and still not be yours.

A system is yours when you can change it, not when you’ve paid for it.

On why the cost has moved from writing code to deciding and maintaining, I wrote what happens when building software stops being expensive. If your problem is a system that already exists and nobody dares touch, legacy modernization explains what gets kept, what gets isolated and what gets rebuilt. And custom software development covers how I build systems your company can evolve without depending on me.