When custom software is economically justified
Custom software is not always the right answer, and neither is another packaged suite. The right test is economic, not ideological.
The debate between 'buy' and 'build' is often framed as a matter of principle. In practice, it is better treated as an economic question with a specific test: does a packaged product require enough workaround, configuration cost, or licence spend that a focused, purpose-built alternative would cost less over its useful life while creating less operational risk?
Packaged software earns its cost when the workflow it supports is genuinely standard across organisations, and the product's roadmap will keep pace with need. Custom software earns its cost when the workflow is specific to how the organisation operates, when a packaged product would require significant configuration or workarounds to fit, or when licence cost has grown disproportionate to actual usage.
A useful way to test this is to map the real workflow, not the vendor's demonstration workflow, and price both paths against a three to five year horizon, including maintenance, licence growth, and workaround cost. The result is often a mixed answer: keep the platform for what it does well, and build a smaller, focused system for the parts that do not fit.
The economics, not the technology preference, should decide the outcome.