The question is about the process, not the tool
Teams usually arrive with a shortlist of products. The useful conversation happens one step earlier: what does this process do that a standard one does not?
If the answer is a real difference in how you serve customers, build it. If the answer is that the current tool does not match a habit, the habit is cheaper to change than the software.
Where buying quietly fails
Off the shelf breaks down when what you sell has rules nobody else has. Unusual pricing, an approval chain with real consequences, a regulated step that has to be evidenced.
It also breaks when the glue costs more than the tools. Three products joined by someone copying between them is not a bought solution, it is a build with the worst part left to a person.
Where building quietly fails
Building fails when the requirement is still a conversation. A scope that changes weekly does not produce software, it produces invoices.
It also fails when nobody owns it afterwards. Custom software needs a person whose job includes it, or it decays into the thing everyone works around.
- The requirement is not written down yet
- Nobody internally will own it after launch
- The advantage disappears the moment it is copied
- A standard tool does most of it and the rest is habit
The middle answer most teams need
The usual outcome is neither: buy the ordinary parts, build the one step that is genuinely yours, connect them properly.
That keeps the surface you have to maintain small, which is the real long term cost of any custom system.