The Software Should Fit the Work, Not the Other Way Around

Somewhere between a spreadsheet that everyone secretly depends on and a system that promises to fix everything, there is usually a more useful question: what does the work actually need?

Choosing software can feel like choosing a future. One product promises simplicity. Another promises limitless flexibility. A third seems to have a feature for every problem you have ever had. It is easy to get caught comparing feature lists and forget the people who will have to live with the decision.

The best choice is rarely the most impressive demonstration. It is the one that helps people do good work with less friction.

When the ready-made answer is the right answer

Off-the-shelf software exists because many needs are shared. Most organisations need to manage accounts, communicate, keep track of projects, or maintain customer information. For these familiar jobs, an established product can offer a sensible beginning: it may be quicker to introduce, already documented, supported by a vendor, and improved over time.

There is no special virtue in building something from scratch if a reliable tool already does the job well. Sometimes the most thoughtful decision is to use what exists and give the team its time back.

The signs of a good fit are often quiet ones. People understand the system without a long explanation. Information reaches the right place. The work can move forward without a second spreadsheet, a private workaround, or someone who knows a mysterious sequence of clicks.

When the work starts bending around the tool

A mismatch rarely announces itself all at once. It may begin with a small workaround: a field that does not quite fit, a report that must be assembled by hand, or two systems that refuse to share information. Someone creates a spreadsheet to bridge the gap. Someone else copies the same detail into another screen. Before long, the workaround becomes part of the process.

That does not automatically mean the software is bad. Every tool has boundaries, and not every inconvenience deserves a custom solution. But repeated workarounds are worth listening to. They can reveal that the system’s assumptions and the organisation’s real work have drifted apart.

Custom software becomes worth considering when the difference matters: when a distinctive process is central to the service, when systems need to work together in a way existing products cannot reasonably support, or when a digital experience is itself part of what makes the organisation valuable.

The point is not to make everything unique. It is to notice where being different actually matters.

Custom does not mean effortless

A tailored system can reflect a team’s language, decisions, and sequence of work. It can remove unnecessary steps and make information easier to follow. But flexibility comes with ownership.

Someone must help define what the system should do. Someone must test it with real situations, look after security, respond when something breaks, and decide how it should change. A custom build is not a finished object that can be put on a shelf; it is a responsibility that continues after launch.

That is why the question is not simply, “Can we build it?” It is also, “Can we look after it?” The answer may involve an internal team, an external partner, or a smaller custom component connected to established products.

Look at the whole cost, including the invisible parts

The price on a proposal is only one part of the story. A subscription may grow as more people use the product or as essential features move into a higher tier. A custom build may require discovery, design, testing, hosting, maintenance, and future improvements.

There is also the cost that rarely appears on an invoice: time spent correcting duplicate records, reconciling reports, explaining workarounds to new colleagues, or waiting for information to travel between systems.

A useful comparison looks beyond the first month. Over a few years, which option makes the work clearer? Which one can the organisation afford to maintain? Which one leaves room for change without creating a different kind of burden?

A lower price is valuable. So is a system that quietly gives people back an hour of their day. The important thing is to understand what is being exchanged.

There may be a third choice

The decision does not always have to be “buy everything” or “build everything.” An organisation might use a mature accounting package, keep its existing collaboration tools, and build one carefully scoped component to connect a particularly important workflow. This can preserve the reliability of established products while addressing the part that genuinely does not fit.

Before making a decision, it helps to describe the problem in ordinary language. What is difficult today? Who feels the difficulty? How often does it happen? What would become easier if the problem disappeared? Those answers are more valuable than a long wish list of features.

A question worth keeping

Imagine that the software disappeared tomorrow. Which parts of the work would people miss because they are genuinely useful—and which parts would they be relieved to leave behind?

That question can reveal more than a product demo. Choose the tool that serves the work and the people doing it, rather than asking the people to keep adapting to a tool simply because it has already been chosen.