For many years, software has been described almost exclusively through its features. More functions, more integrations, more speed, more automation. Today, naturally, more artificial intelligence.
Every new platform promises to simplify, optimize, transform. Yet, looking at real work — the work of people, operators, small businesses, activities that exist outside commercial presentations — a different feeling often emerges: despite all this technology, many businesses seem more fragile today, more dependent, more confused than before.
This isn't a random impression.
The right way to evaluate "software"
In recent years we've learned to judge software almost exclusively in terms of features, forgetting a much more important question: who takes responsibility for the operational consequences of what gets built?
It's a less spectacular question than AI demos or animated dashboards. But it's the question that determines whether a system will truly help people, or add a new layer of invisible complexity.
This difference shows up especially in real contexts, where processes aren't linear and work doesn't behave the way it does in diagrams.
Many platforms are designed far from the place where they'll be used. Whoever builds the system often doesn't live in the territory, doesn't follow the operators, doesn't see the daily exceptions, and doesn't bear the consequences of the errors. Slowly a fracture forms: the software starts representing a theoretical reality instead of the real one.
Processes become abstract models. People become users. Human presence gets replaced by standardized flows and procedures.
This works as long as everything seems fine. Then real work arrives.
Software and real problems
The plumber who gets three simultaneous emergencies in different parts of the territory through an insurance platform that's practically impossible to integrate with other systems. And indeed almost no one really integrates it. Operational reality keeps living elsewhere: on paper diaries, in WhatsApp messages, between Google Maps, phone calls and personal memory.
Or the tourist property that discovers an electrical problem at 10:30pm, with a guest who just arrived. Or the property manager who moves constantly between regulations, maintenance, human relationships and different platforms that don't talk to each other.
That's where the difference becomes clear between a system built to look efficient and a system built by taking on operational responsibility.
Contemporary technology has developed a kind of obsession with features. Every product is described with words like automation, AI integration, predictive intelligence, smart workflows. Much more rarely does anyone talk about the dependencies created.
The life of a piece of software
Who will maintain that system a year from now? What happens when an external service changes its API? Will operators really understand what's happening, or will they work inside an opaque box? Is there a way to intervene manually when something fails? These aren't technical questions. They're questions of responsibility. And yet they almost always slow down technology's commercial narrative, which prefers to focus on possibilities rather than consequences.
One of the more interesting things about automation is that it often doesn't eliminate work. It moves it.
Software that doesn't help
Many digital systems reduce the visible work of the company selling the software, while increasing the invisible work of the end operator. The platform 'simplifies', but in the meantime it demands constant updates, generates a steady stream of notifications, fragments information, forces people to act as a bridge between different systems, and pushes operators to keep adapting to the platform's logic.
Real work doesn't disappear. It gets redistributed. Very often toward whoever has less time, less support and less decision-making power.
In tourism, maintenance, real estate and small business this is now clear to see. Many professionals spend more time coordinating software than doing their actual job.
There's an even deeper problem underneath: the loss of context.
Software and its context
A territory isn't a uniform dataset. An operator isn't an abstract node. An urgent repair isn't simply a ticket to assign.
Every real activity contains relationships, experience, exceptions, local knowledge, trust, history and perception. These are elements that are hard to turn into standardized workflows, which is exactly why centralized systems often ignore them.
Contemporary technology tends to value what's easily measurable, slowly pushing everything hard to model into the background. And yet, very often, it's precisely what can't be easily modeled that determines whether a service actually works.
In recent years we've started talking a lot about AI ethics, but much less about operational transparency. Yet the problem, in most cases, isn't that a system is "intelligent". The problem is that it becomes opaque.
When people no longer understand why something is happening, where the data lives, who really controls the process, or what dependencies exist, software slowly stops being a tool and becomes an environment to endure. This is especially critical for small organizations, which rarely have the time or expertise to understand increasingly complex systems. That's why transparency isn't a secondary feature. It's infrastructure.
Slow software
A good system should let people understand what's happening, verify processes, intervene manually, and keep operational autonomy even as the software evolves.
Maybe one of today's problems is that we've started treating slowness as an absolute flaw. And yet many reliable systems are intentionally slow. Slow in the sense that they favor understanding over speed, continuity over novelty, clarity over complexity, and responsibility over indiscriminate scale. This doesn't mean rejecting technology. It means remembering that a system's value doesn't depend only on what it can do, but also on what it makes understandable, what it preserves, and the kind of dependency it creates.
Software that helps
Features matter, of course. But they come after. First there should be another question, much simpler and much harder at the same time: does this system really help people keep control, understanding and responsibility over their own work? If the answer isn't clear, it's probably not yet the moment to automate.
For many years technology has mostly tried to increase possibilities. Maybe in the coming years it will become more important to understand what responsibilities we're willing to take on when we build systems meant to enter people's real lives.