Build or buy: the question that actually settles it

Cost comparisons mislead

A subscription has a visible price. Building has an invisible one: the engineering time, plus every hour of maintenance for as long as the thing exists. Teams compare the visible number to a one-off build estimate and reach the wrong conclusion regularly.

The question that settles it

Is this capability how you win, or is it table stakes?

If a customer would choose you because of it, build it. Your differentiation should not be something a competitor can subscribe to.

If it is simply required — authentication, payments, email delivery, error tracking — buy it. Nobody chose a supplier because their password reset flow was better.

The middle case

Some capabilities start as table stakes and become differentiation later. The sensible pattern is to buy first, learn what you actually need from real usage, and only build once you can name the specific thing the bought option cannot do. Building on a guess about future differentiation is how teams end up maintaining a worse version of something they could have rented.

What to check before buying

• Can you export your data in a usable form?
• What breaks if the vendor doubles the price or shuts down?
• Does it work in the languages and regions you serve?

These are the questions that determine whether "buy" was cheap or merely cheap-looking.