Technology and Long-Term Thinking

‍

Every few years, business software gets a new religion.

‍

Big data. Blockchain. The metaverse. Now AI agents. Each arrives with the same sermon: everything you built is obsolete, and everyone who hesitates is doomed.

‍

Meanwhile, somewhere in Switzerland, a forty-year-old core banking system quietly processes another million transactions before lunch.

‍

Both of these things are true at the same time. That tension is what this paper is about.

‍

We built our practice around a promise, software that lasts, which forces an awkward question: what actually makes technology last?

‍

After two decades of building systems, and being called to the funerals of many built by others, we keep seeing the same five traits in the durable ones. None of them are glamorous.

‍

They are boring at the foundation. Databases, queues and languages with a decade of production scars. Novelty is fine at the edges of a system. At the core, novelty is a mortgage with a variable rate.‍

They have one owner. Not a committee, not a rotating cast of vendors. One person or team who can explain why the system is the way it is, and who feels it when it breaks.‍

They have few dependencies, chosen slowly. Every library, platform and vendor is a marriage. The systems that last are the ones that said no often, and said yes only to partners likely to still exist in ten years.‍

They are written down. Not novels of documentation, just the decisions and their reasons. A system whose logic lives in one engineer's head has that engineer's notice period as its lifespan.‍

They leave room to change their mind. Modular enough that a decision made in 2026 can be reversed in 2029 without a rewrite. Durability is not rigidity. It is the opposite.

‍

Notice what is not on the list: the newest framework, the biggest platform, AI.

‍

Trend-chasing is expensive in a way that never shows up on the invoice.

‍

The cost is not the license. It is the migration, the retraining, the two systems running in parallel "temporarily" for three years, the institutional knowledge thrown away with every restart.

‍

A full rewrite resets your bug count to zero by deleting ten years of fixes for problems you have forgotten you ever had.

‍

Long-term thinking is not refusing new technology. That is just nostalgia with a firewall.

‍

It is asking a different question at the moment of adoption. Not "what does this do for us this quarter?" but "what will this cost us to still own in ten years?"

‍

AI passes that question, by the way. Not because it is fashionable, but because it is a capability rather than a product, closer to electricity than to a gadget. The durable move is not bolting a chatbot onto your website. It is wiring your data and your processes so that any model, this year's or the ones coming in 2033, can plug in and do work.

‍

Here is the part we find genuinely optimistic: SMEs are built for long-term thinking.

‍

A family-owned company thinks in generations. A Swiss Treuhand thinks in decades of client relationships. Their instincts are already right. The problem is that their technology rarely matches their time horizon. It matches their vendor's sales cycle.

‍

Enterprises can afford to burn money on fashion. An SME cannot, which is exactly why the SME advantage is choosing technology the way it chooses people: carefully, for the long run, with attention to character over charisma.

‍

The most valuable thing a technology decision can buy you is not speed. It is optionality: the ability to make the next decision cheaply.

‍

And that points at the real conclusion.

‍

The technology that lasts is not the technology that never changes. It is the technology built so that change does not kill it.

‍

‍

Frequently Asked Questions

Should we modernise our legacy system or replace it? In most cases, modernise incrementally. A rewrite feels cleaner but throws away years of accumulated fixes and forces the business to fund two systems at once. Replace only when the foundation itself blocks you: the platform is dead, the skills are gone, or the architecture cannot express what the business now does. Either way, decide from an inventory of facts, not from frustration.‍

How do we adopt AI without chasing hype? Treat AI as a capability, not a purchase. Get your data accessible and your processes described, then pick one narrow, measurable use case and put it into production properly. A company that does this once has built the wiring for everything that follows. A company that buys ten AI tools in a year has built ten new dependencies.‍

What makes software "last" in practice? Boring foundations, a clear owner, few and carefully chosen dependencies, written-down decisions, and an architecture that lets you reverse choices without starting over. Longevity is a property of decisions, not of any particular technology.‍

Is long-term thinking slower? Only in the first month. Durable foundations make every following feature cheaper, because you build on top of things instead of around them. Most of the slowness in old systems is not age. It is the accumulated cost of short-term decisions nobody went back to fix.‍

How should an SME budget for technology over the long term? Budget for ownership, not acquisition. A serious system costs its build price again in care and evolution over the following years, and that is healthy: it means the system is alive and adapting. The expensive pattern is the cycle of neglect and panic replacement every five years. Steady maintenance is cheaper than serial funerals.

‍

‍

If you have thoughts, feedback, or questions, we'd genuinely like to hear them. Reach out directly to the author, Dejan Georgiev at:##INLINE1##