Off-the-shelf software is a good start. For most work, it's even enough.
The trouble is in the word "most."
A tool that solves eighty percent struggles with the twenty
Standard software on the market is designed to serve a broad audience. That is its strength: it solves common needs quickly and cheaply.
But every operation also has a part that is unique to it. An industry-specific rule, an unusual flow, the requirement for multiple systems to work together.
And it's this twenty percent that is, more often than not, the lifeblood of the business.
And this is exactly where standard software struggles. To squeeze in the part that doesn't fit, the business process gets bent to the software. The team starts working around the tool's constraints. Spreadsheets step in. "Temporary" workarounds become permanent.
Forcing the tool isn't a solution
Pushing a tool beyond its limits produces two costs:
Visible cost: add-ons, integrations, consulting, constant fixes.
Invisible cost: the operation sacrificing efficiency to adapt to the software. This line item doesn't appear on the invoice, but it's paid every day.
Past a certain point, the cost of keeping off-the-shelf software on its feet exceeds the cost of building the right system.
The right question: force it, or design it?
The decision framework is actually plain. You ask these questions:
- Does the process fit the software, or is the software being forced onto the process?
- Do multiple systems need to work together?
- Does an industry-specific rule fall outside standard tools?
- Have "temporary" workarounds become permanent?
The closer the answers move to "yes," the less sense it makes to keep forcing off-the-shelf software.
In such cases, the right approach isn't to force an existing tool. It's to build a system designed for the operation.
A custom system doesn't mean a complex system
The common misconception here is this: custom solution = expensive, long, risky project.
Done right, it's the opposite. A custom system solves only that operation's need. It carries no excess, holds no unnecessary modules. It starts with process analysis, integrates with existing tools and data, and settles into a scalable structure.
First the operation is examined. The need is clarified. A system-specific, scalable structure is designed. It fits seamlessly with existing tools and data.
Anything with an operation can be turned into a system. The point isn't to force in the part that doesn't fit, but to design around it.