When a process is painful, the question usually arrives framed as a choice between two options: buy the vendor module, or build something custom. Both are expensive, and the framing hides a third option that is often better than either.
What buying actually costs
The licence is the visible number. The real cost is the configuration work, the data migration, the retraining, and the degree to which your process has to change to match the module’s assumptions. That last one is the expensive part and the one least likely to appear in the business case.
Buying makes sense when the process is genuinely generic — payroll, general ledger, standard tax reporting. If a thousand other companies do it the same way, someone has already built it better than you will.
What building actually costs
Building makes sense when the process is the business — the thing you do differently from competitors, where bending to a vendor’s model would erode the advantage. The cost is not just the initial build; it is owning the thing for its whole life.
Which is fine, provided you go in knowing that. The failure mode is building something custom for a generic process, then maintaining it forever because nobody wants to admit it should have been bought.
The third option
Most of the pain we are asked to solve is not in a system at all. It is in the gap between two systems — re-keying, chasing approvals, assembling the same report weekly, reconciling two versions of one number.
You do not need a new system for that. You need the existing ones to exchange data reliably and the manual steps between them removed. That is usually faster to deliver, cheaper to own, and considerably less disruptive than either buying or building.
A question that settles most cases
Ask whether the process is a competitive advantage or a cost of doing business. Advantages are worth building. Costs of doing business are worth buying or automating — and if the systems already exist and merely fail to talk to each other, automating is almost always the cheapest correct answer.
We work through this with clients before anything is committed — see custom software development and AI workflow automation. Related: custom developed software vs off-the-shelf and where the money actually goes.
Common questions
When is buying an ERP module the right call?
When the process is genuinely generic — payroll, general ledger, standard tax reporting. If a thousand companies do it nearly identically, a vendor has already built it better and maintains it for a fraction of your cost.
What is the third option people miss?
Keeping the systems you have and automating the joins between them. Much of what is described as a software gap is really the cost of humans copying data between systems that do not talk. That is often far cheaper to fix and, unlike a build, reversible.
How do we decide quickly?
Describe the process to someone outside your industry. If they ask why you do it that way and you have an answer that connects to how you win business, it is a build candidate. If the honest answer is that the last system worked that way, buy something.
