A lot of the time the client would be better off buying actual custom software. It's very easy to end up with a SAP (say) "configuration" so complex that you'll spend more on maintenance than you would if it were a standalone program.

> A lot of the time the client would be better off buying actual custom software.

I agree in theory, but I thoroughly disagree in practice.

If a client could spec/develop good software and cost it realistically, then sure. But I have rarely had clients like that - instead they think the problem-space is simple and end up with a half-baked solution that can't be maintained.

Developing greenfield software is a high risk strategy. (Edit: with a high reward if core function, and not much reward if not core).

The pretence that there's cost savings, followed by the sunk cost fallacy.

This happens because management is doing cover-your-ass methodology of software procurement. If they backed a greenfield development and it failed, then get blamed. But if they choose SAP/salesforce/bigCo, the same failure can be blamed on the vendor, or if it ran over budget, they can claim the vendor is expensive.

That's very true but still, in my experience anyways, it's much easier (i.e. perceived as 'less risky') to buy SAP and attempt to roll it out than to convince others that custom software would be better.

'Custom' is scary in a way that 'customizable' isn't.

It's hard not to wonder what might happen if more managers and executives became aware of "The Inner Platform Effect" and that "customizable" often just means "custom, but a worse, more expensive programming language".