Build-versus-buy usually gets argued on price, which is the least reliable input. Licence costs are legible and build costs are not, so the comparison flatters whichever option the person running it already preferred.
A better question: is this process how you win, or is it just how you happen to work?
Buy the parts that are the same everywhere
Auth, billing, payments, email delivery, error tracking, log aggregation. Nobody has ever won a deal because their authentication was bespoke. These are solved, boring, and someone else is paid to keep them working at 3am.
Building them is the most common way engineering budget disappears without producing anything a customer notices.
Build the part that is yours
Then there is the process that is actually specific: how you price, how you route work, how you decide what a customer sees next, the thing your operations team does that competitors cannot copy from your website.
That is worth building, and it is usually the thing teams try hardest to force into an off-the-shelf tool — because it is the hard part. The result is a configuration so elaborate that it is a custom application anyway, just one you cannot test, version or debug.
The tell: how much workaround is around it
A useful diagnostic is to count the workarounds. If the tool needs a spreadsheet beside it, a weekly manual export, a rule nobody can explain, and one person who "knows how it works", you have already built a system. You have just built it out of human attention rather than code, and it does not scale or survive that person leaving.
The middle path is usually right
The answer is rarely all-build or all-buy. It is: buy the commodity layer, build the twenty per cent that is genuinely yours, and be deliberate about the seam between them.
Where teams get hurt is the seam. Data lives in two places with no agreed owner, and the integration becomes the most fragile part of the stack. Decide up front which system is the source of truth for each entity, and make the other one derive from it rather than argue with it.
What actually costs money later
Not the build. The absence of a decision.
Systems that were never deliberately chosen accumulate: three overlapping tools, two half-migrations, and nobody willing to turn anything off. That is more expensive than either building or buying, and it is the default outcome when nobody asks the question at all.