Theory
When Zero Neo should fail
The conditions under which specialized software remains the right answer, stated precisely enough to be used in an actual review. Where requirements are certified, regulated, or deep in domain logic, Zero Neo has no claim and the hypothesis is treated as rejected. New software is the last resort, and sometimes that is where a case ends up.
Where buying still wins
Deep domain-specific functionality that took a vendor a decade and a regulated user base to get right. Regulated systems of record. Specialized clinical functionality. Complex accounting and ERP. High-volume transaction processing. Specialized manufacturing. Industry-specific compliance regimes with certification requirements. Complex supply-chain systems. High-performance transactional systems. And anything where the owned platform simply cannot meet the requirement, however it is configured.
In these cases the configuration tax is not the binding constraint, so reducing it changes nothing. Zero Neo has no claim on them and should not pretend otherwise.
The gate
One question, asked before anything is designed or bought, with three permitted answers.
Rejection criteria
The hypothesis should be treated as rejected for a given case when any of these hold: the requirement is certified or regulated in a way the platform cannot satisfy; the volume or latency exceeds what platform services support; the domain logic is deep enough that reproducing it would take longer than the product's remaining useful life; the assembled version cannot be observed or audited to the standard the work requires; or the total operating cost, honestly measured, exceeds the purchased alternative.
The doctrine is not never buy software. It is that new software is the last resort, and the last resort is sometimes exactly where you end up.