We sell packaged platforms and we take on custom builds, so we have an interest either way and no particular incentive to push you toward one. What follows is the reasoning we actually use when a client asks.
The honest position is that custom is right far less often than businesses believe, and more often than vendors of packaged software will admit.
The test
Ask this about the process you think needs custom software: does it win us business, or is it just how we have always done it?
A distributor whose route planning is genuinely better than its competitors’ has something worth encoding. A distributor whose order form has an unusual column order does not. Most things described as unique are the second kind, and the honest response is to change the process rather than build software to preserve it.
Where a process really is a competitive advantage, packaged software will erode it by forcing you toward the industry-standard way of working. That is the case for building.
What custom actually costs you
Not the build. The build is quotable and finite. What custom costs is everything afterwards.
Nobody else maintains it. There is no upgrade path arriving with new features someone else paid to develop. There is no community, no Stack Overflow answer, no second vendor to switch to. When the people who built it move on, the knowledge goes with them unless it was documented properly, which it usually was not.
Budget for custom as a permanent operating cost rather than a project. If that cost is uncomfortable, buy.
The middle path most businesses actually want
Packaged core, custom edges. Finance, stock, purchasing and payroll are not where anyone competes — take those from a product. Build only the layer that is genuinely yours, and connect it through a documented interface.
This gets you upgrades on the commodity parts and control where it matters. It also keeps the custom surface small enough that losing a developer is an inconvenience rather than a crisis.
Warning signs for each direction
Reasons to stop and reconsider, in both directions.
- Building because no product fit the requirements document
- If the requirements were gathered by asking everyone what they want, the document describes the current process, not the needed one. Rewrite it before concluding nothing fits.
- Building to avoid licence fees
- The build will cost more than several years of licensing, and then keep costing. This reasoning almost never survives the arithmetic.
- Buying something that needs heavy modification
- A product customised past a certain point has the cost profile of custom software and the constraints of a package. That is the worst of both.
- Buying because a competitor uses it
- They have different problems. Find out whether theirs resemble yours before inheriting their choice.
Common questions
Is custom ERP cheaper than buying?
Almost never over three years, once maintenance, the absence of an upgrade path and key-person risk are counted. The build price is the smallest part of the cost.
When does custom software genuinely make sense?
When the process encodes a real competitive advantage that packaged software would erode by standardising it. If the process is merely familiar rather than advantageous, change the process.
What is the usual middle path?
A packaged core for finance, stock and payroll, with custom only at the edge that is genuinely yours, connected through a documented API. You keep upgrades on the commodity parts and control where it matters.