Every operations team has a story about the software that was supposed to fix everything. The platform that arrived with a hundred features, a polished onboarding experience, and a sales deck full of customer logos — and then, within six months, was being worked around with spreadsheets and WhatsApp threads.
This isn't a coincidence. It's a structural problem with how generic software is built.
What Generic Software Is Optimized For
Generic software — CRMs, ERPs, project management tools, field service platforms — is built to serve the largest possible market. That means it's optimized for the median use case across a large and diverse set of customers.
The median use case is not your use case.
Your operation has specific sequence requirements, approval chains, data fields that exist nowhere in any standard data model, exception-handling rules that took years of operational experience to define, and integration points with other internal systems that no product manager at a software company has ever heard of.
Generic software can't accommodate these specifics — not because the software is bad, but because accommodating them would make the product unmanageable for everyone else.
The Workaround Tax
When software doesn't fit a workflow, teams adapt. They create workaround processes — parallel spreadsheets that capture the data the software doesn't have a field for, manual steps that bridge two systems that don't integrate, informal communication channels that carry the operational context the platform can't represent.
These workarounds are invisible to management until they break. And they always break — when the person who built them leaves, when the volume grows beyond what a manual process can handle, or when a critical piece of context gets lost in transit between systems.
The cost of workarounds is real but hard to measure: it lives in the extra minutes per task, the duplicate data entry, the errors discovered too late, and the institutional knowledge that exists only in someone's head.
Why Customization Isn't the Answer
Most generic platforms offer customization — custom fields, custom workflows, custom integrations. It's tempting to assume this solves the fit problem.
It doesn't, for two reasons:
Customization is bounded. You can add fields to a form, but you can't change the fundamental data model. You can configure a workflow, but only within the options the platform supports. The deeper your operational specificity, the sooner you hit the ceiling of what customization can reach.
Customization creates fragility. Every customization is a dependency on a specific platform version, a specific API, or a specific configuration that must be maintained as the platform evolves. Custom integrations built on top of generic platforms are notoriously brittle — they break on platform updates, rate limit changes, and deprecation cycles that the platform vendor controls.
What Custom Software Actually Costs
The objection to custom software is always cost. And it's true that a well-built custom system requires a meaningful upfront investment.
But that calculation changes when you account for:
- The ongoing cost of workarounds and manual processes
- The license cost of a generic platform that doesn't fully serve the workflow
- The cost of failed implementations and re-platforming cycles
- The opportunity cost of operational inefficiency that never gets resolved
In our experience, organizations that have been running a generic platform for more than two years and still relying heavily on manual workarounds are almost always better served by a focused custom build — one that addresses exactly the workflow they have, not the workflow a generic vendor imagined.
What Good Custom Software Looks Like
Good custom software is not a blank canvas with unlimited features. It's a focused system built around a specific operational workflow with:
- A data model that reflects the actual entities in the operation, not a generic approximation
- Workflows that encode the actual sequence and rules of the operation, including exceptions
- Integrations with the other systems in the stack, built to the exact data contracts needed
- An interface designed for the people who will actually use it, not for a general user persona
The scope is intentionally narrow. A system that does one operational workflow exceptionally well is more valuable than a platform that does ten workflows adequately.
The Principle
Software should adapt to workflows. When the reverse happens — when workflows adapt to software — operational intelligence gets lost, and the organization becomes dependent on a vendor's product roadmap for its own operational evolution.
That's a dependency worth eliminating.