Stop buying software to avoid a hard decision
New tools do not fix unclear ownership, messy rules, or a workflow the business has not agreed on.
Buying software can feel like progress. It creates movement, gives the team something to trial, and makes the problem look like it has an owner.
Sometimes that is useful. Often it is avoidance.
The hard decision might be who owns the workflow, which system is the source of truth, which exceptions matter, or which part of the process should stop existing. A new tool will not answer those questions for the business.
Tools expose unclear decisions
Most software implementation problems are not really software problems.
They are unresolved business decisions showing up in the tool:
- Two teams disagree on the process.
- No one owns the final approval.
- The data is trusted only after manual checking.
- Exceptions are handled differently by different people.
- Reporting requirements change depending on who asks.
- The business wants automation but has not agreed on the rules.
Software can support a decision. It cannot replace one.
The source of truth matters
One of the most important decisions is where truth lives.
If customer status lives in the CRM, then operations needs to respect that. If job status lives in the job system, then reporting should not depend on a separate spreadsheet. If finance owns invoice state, then another tool should not quietly invent its own version.
When the business avoids that decision, staff end up reconciling competing truths.
That is where manual admin comes back.
What to decide before buying
Before buying another tool, answer:
- What workflow are we fixing?
- Who owns the workflow?
- What system owns each important record?
- Which rules are stable?
- Which exceptions need human judgment?
- What should happen when the process fails?
- What report would prove this is working?
If those answers are unclear, the next tool will inherit the mess.
When a new tool is the right move
Sometimes buying software is exactly right.
Use an existing tool when the workflow is standard, the business can adapt to the tool's way of working, and the integration cost is low.
Build or customise when the workflow is valuable, specific, and painful enough that forcing it into a generic tool creates more work than it removes.
The decision is not "buy versus build". The decision is whether the workflow is clear enough to support either option.
The practical rule
Do not buy software because the business is tired of the problem.
Buy or build once the business has made the decisions the software needs to enforce. That is when technology starts removing work instead of moving it somewhere else.
