When to Build Custom Software (and When Not To)

Off-the-shelf software represents thousands of engineering hours invested in solving problems that most organisations share. A CRM, an accounting system, a project management platform, a payroll system — these are solved problems. The organisations that have built custom versions of them have spent significant engineering resources solving a problem that existing software solves adequately, freeing no engineering capacity for the problems that are genuinely differentiating.

The bias toward custom development is driven by frustration with off-the-shelf limitations and by the appeal of software that is exactly what the organisation wants. Both are understandable. Neither justifies the full cost of custom development: the initial build cost, the ongoing maintenance cost, the opportunity cost of engineering capacity spent on undifferentiated software, and the eventual migration cost when the custom system reaches the end of its useful life.

• The core operation of the business is not adequately served by any existing platform — the workflow is genuinely differentiated, not just customised
• Integration requirements cannot be met by existing platforms without building so much custom integration logic that the off-the-shelf core provides no remaining value
• Data ownership, compliance, or security requirements preclude the use of any cloud-hosted solution
• Transaction volume or performance requirements that existing platforms cannot meet at acceptable cost
• The organisation's competitive advantage is directly derived from the capabilities of the software — the software is the product

The common thread is specificity. Custom development is justified when the operational requirement is specific enough that no existing solution adequately addresses it, and the cost of that gap — in operational inefficiency, competitive disadvantage, or compliance risk — exceeds the cost of building and maintaining a custom solution. Generic frustration with off-the-shelf software does not meet this bar.

The build cost is visible. The maintenance cost, the technical debt carrying cost, and the eventual migration cost are not. The total cost of custom software ownership is consistently underestimated.

Custom software has a maintenance cost that accumulates indefinitely. Dependencies require updates. Security vulnerabilities require patching. Infrastructure requires management. Operational issues require investigation and resolution. Business process changes require engineering work. Each of these is a cost that off-the-shelf software carries on behalf of its customer base and that custom software's owner carries alone.

The maintenance cost also grows with time. A custom system built today will require progressively more investment to maintain as its dependencies age, as the team that built it turns over, and as the business requirements it was built to serve evolve. The organisation that commits to custom software is committing to ongoing investment in that software or accepting the eventual cost of migration when the system reaches the end of its serviceable life.

The binary of build-everything vs buy-everything misses the approach that provides the best outcomes for most organisations: use off-the-shelf software for solved problems and build custom software for the specific differentiating operations that existing platforms cannot adequately support. This requires honest assessment of which operations are genuinely differentiating and which are shared with every other organisation in the sector.