The enterprise tool you already own usually wins
Custom software is the right answer less often than the market pretends. A framework for deciding when to build, when to configure, and when to do nothing.
Kicker · June 29, 2026
A meaningful share of our systems engagements end with a recommendation that we build nothing.
That is not modesty. It is arithmetic. Custom software has a purchase price and a much larger ownership price: hosting, dependency updates, security patching, the person who understands it, and the eventual rewrite when that person leaves. A configured platform has a subscription and a vendor with a security team, an SLA, a compliance program and several thousand other customers finding the bugs before you do.
The three-question filter
1. Is this process your actual competitive advantage?
If a competitor could buy the same software and run the same process and it would not matter, the process is not your advantage. Configure it. Save the custom build for the thing you do that nobody else does.
2. Does something you already pay for do eighty percent of this?
Most mid-sized companies are running at maybe forty percent of the capability they are already licensed for. Microsoft 365, Google Workspace, and most ERPs contain entire product categories that customers pay separately for elsewhere. Before scoping a build, audit the shelf.
3. Who owns it in eighteen months?
If the honest answer is “nobody,” you have not scoped a system. You have scoped a future problem. Every automation we ship has a named internal owner, a runbook, monitoring and an alert path — and if no such person can be identified, we say so before building rather than after.
When building is right
There is a real category where custom wins, and it is not small:
- The process is the product, and the platform’s model genuinely does not fit
- Integration between systems that will never natively speak to each other
- A workflow with regulatory requirements no off-the-shelf tool takes seriously
- A customer-facing experience where the platform’s ceiling is your ceiling
The distinction is whether the constraint is incidental — the tool is awkward — or structural — the tool cannot express what you do.
The uncomfortable middle
Most requests land in a third category: the process is fine, the tool is fine, and the actual problem is that nobody has agreed on who does what. No software fixes that, though a lot of software has been sold as though it does.
Those engagements end with a process document and a much smaller invoice. We have never regretted one.