The usual framing pits development cost against a subscription fee, runs the math, and picks the cheaper column. That framing is almost always wrong, because it measures the easy thing — money now — and ignores the hard thing — control later.
Ask what is core
The better question is: does this capability differentiate you? If it is the thing customers choose you for, own it — build it, control its roadmap, and let it compound. If it is table stakes that everyone needs and no one wins on, rent it, and spend your scarce engineering attention where it actually moves the needle.
Build what makes you different. Buy what makes you the same as everyone else.
Count the real costs
Buying has costs the sticker price hides: integration effort, lock-in, and the ceiling of someone else's roadmap. Building has costs the estimate hides: maintenance, on-call, and the opportunity cost of every engineer-week you spend reinventing a solved problem. A clear-eyed decision counts both columns honestly.
Decide reversibly
Where you can, make the decision easy to undo. Abstract behind a clean interface so a bought component can be swapped, or a built one replaced by a vendor later. The goal is not to be right forever — it is to avoid being trapped by a choice you made with incomplete information.
That is the heart of good technology consultancy: not a preference for building or buying, but a framework for deciding which is which — and the discipline to keep the decision reversible.