Every line of custom code is a line you maintain forever
Configuration inside a product you already pay for stays supported when the vendor ships an update. Custom code does not. That difference compounds, and it is usually the whole decision.
There is a moment in most implementations where the system almost does what is wanted, and someone suggests building the difference. It is nearly always presented as a small piece of work, and in delivery terms it usually is. The cost is not in writing it.
What configuration gets you that code does not
It survives upgrades. When the vendor ships a new version, supported configuration comes with it. Custom code is tested by you, against each release, forever. This is the difference that compounds.
It is documented by someone else. A configured workflow is described in the vendor's documentation and understood by anyone who has worked with that product. A custom module is understood by whoever wrote it.
It can be changed by someone who is not a developer. Which means it gets changed when the business changes, rather than joining a backlog.
It is portable between people. Hiring for a known product is a different exercise from hiring someone to take over an undocumented internal system.
The costs that do not get quoted are regression testing it against each vendor release, changing it as the business changes, and the time someone spends relearning it after whoever wrote it has gone.
When building is right
This is not an argument against custom software. It is an argument against building things that did not need building.
Build where the process is genuinely specific to how your business operates and no product covers it, the thing you actually do differently from your competitors, which is usually one or two workflows rather than the twenty in a requirements document. Build where the integration between two systems is the value, which is common and legitimately custom. And build where the configuration required to avoid building has become so elaborate that nobody can explain it, which is a real threshold that gets crossed more often than people notice.
The question to ask about any customisation request
Not "can the system do this", because the answer is almost always yes with enough work. Ask: what happens if it does not?
Frequently the honest answer is that a person does something slightly differently a few times a week, and that is an acceptable outcome. The requirement was inherited from how the old system worked, and it was never examined because examining requirements is uncomfortable and adding them is not.
The ones that survive that question are the ones worth building, and there are usually a lot fewer of them than the list you started with.
What to do this week
Take the customisation list from your current or most recent implementation and mark each item with what actually happens if it is not built. Anything where the answer is "someone does it manually, occasionally" goes into a second list and waits six months. If nobody asks for it in that time, the list has answered the question.
Where this goes next
Configuration is one of the six workstreams in what software implementation actually covers. The same build-versus-buy reasoning applied to AI specifically is in build an AI agent or buy an AI tool, and where customisation lands in the total bill is in the licence is not the cost of the system.