Technology as catalogue vs technology as decision

Most bad technical decisions don’t come from a lack of options. They come from choosing by catalogue: comparing feature lists, ticking boxes and calling that a decision.

Technology as decision is something else. It starts from the operational problem, weighs the consequences and keeps things in proportion. A feature only matters if it changes how the business runs. Without that criterion, the choice looks rational and turns out expensive.

Catalogue or decision

In catalogue mode, the conversation starts with the product: what it has, what the other one also has, which one promises more integrations, more modules, more automation. This mode is comfortable because it feels like an objective comparison, but it hides what matters most: the actual business the thing will have to live in. The result is an “available” integration nobody can maintain, an automation that duplicates a badly defined process, or custom software commissioned because what the market offers isn’t impressive enough.

When the list is long, the temptation is to use everything, and you end up building complexity the team never asked for and the business cannot sustain. Then comes the technical debt: fragile systems, manual work patching over failures, decisions put off because fixing things already costs too much.

The same examples keep coming up. A team chooses a warehouse management system on the strength of its spec sheet and, six months later, half the inventory is still being reconciled by hand because nobody mapped the warehouse’s real exceptions. Another picks a ticketing system by counting modules and ends up with queues and portals nobody maintains, while first-line support carries on in the inbox. Another buys an analytics and reporting tool on the back of a demo, and the dashboard sits there with no owner, no reliable source and nobody to correct it when the numbers stop adding up. The catalogue didn’t lie about the features. It left out how the business actually runs.

In decision mode, the opening question is different: what is failing today, who gets held up, what information gets lost between systems, and which decision is left hanging because nobody trusts the data. Only then do you choose the means, which might be a limited integration, automation of one critical flow, custom software, or cutting a process rather than digitising it. Technology comes in as an answer, not as a starting point.

Deciding means accepting trade-offs: a simpler solution may leave features out, and a more stable, maintainable one may take longer to deliver. The criterion isn’t the most complete list; it’s the best outcome for the business, within the deadline and with the capacity actually available. What matters is the real user, not the demo user: the person who opens the system tomorrow, finds the error and needs a clear way to fix it. If that person can’t operate what was chosen, the decision has failed, whatever the list says.

The cost of choosing badly

Choosing by catalogue has a price that rarely shows up in the proposal.

Technical debt: systems connected in a hurry, with no clear owner and no maintenance discipline, where every temporary fix adds friction until what seemed quick at the start becomes slow every single day. Exhausted teams: the people doing the work end up bridging tools that don’t talk to each other, manual work stops being the exception and becomes the method, and the internal conversation shifts from improving the flow to surviving it. Postponed decisions: when the choice was made from the list rather than the problem, nobody knows what to cut, everything seems important, nothing gets settled, and technical responsibility gets lost somewhere between the supplier, the internal team and the silences.

None of this requires bad faith. It only requires the illusion that comparing features is the same as deciding. It isn’t. Comparing is useful once there is a criterion; before that, it’s organised noise.

A practical rule

Before choosing technology, write down three things in operational terms: the problem that actually has to be solved, and what explicitly will not be; who takes responsibility for maintaining whatever is built or connected; and what happens to the business if the solution fails or is left half-finished.

If you can’t answer all three, you’re not deciding yet; you’re comparing options without a criterion.

This rule doesn’t reject advanced tools. It rejects getting the order wrong: buying complexity before understanding the problem. It also rejects the idea that more features make for a business that runs better; often they just mean more ways for things to fail.

A quick test: if the justification for the choice fits in one paragraph about how the business runs, you’re on the right track. If it only fits in a comparison table, start again.

How we think about this at YOMATICO

We work as a technical partner on real systems, and our criterion is always the same: understand before proposing, define the right problem, choose what is proportionate, execute with rigour, stay accountable after delivery.

That means saying no when the request is a list without context. It means preferring one clear integration to a bloated package. It means treating automation and custom software as means, not as proof of ambition.

There is no shortcut, only responsibility. Good technology is technology the business can live with, maintain and correct. The rest is catalogue. When we step in, what we stand up for is this criterion, not a brand of tool.

The next time someone brings you a feature comparison as if it were a decision, ask what the operational problem is, ask about the consequences, ask who is responsible after delivery. If the conversation stands up to those questions, you’re on the right track. If it doesn’t, you’re still choosing by catalogue, and a catalogue doesn’t run a business.