Build vs. Buy: The Framework We Use When the Answer Isn't Obvious

Build-vs-buy decisions usually get framed as a cost comparison — the vendor's license fee versus the engineering team's fully loaded cost to build the same thing — and that comparison is almost always wrong, in both directions. It undercounts the real cost of buying (integration, data gravity, the eventual migration off a vendor that gets acquired or sunsetted) and it undercounts the real cost of building (the ongoing maintenance burden, which usually exceeds the initial build cost within two years). We use a framework built around two questions, and the cost comparison only matters once those two are answered.

Is this capability actually differentiating for your product

The first question is whether the capability is something customers choose you for, or something they simply expect to work. Authentication, billing, transactional email, and observability are rarely differentiating — customers don't pick a product because its login flow is superior, they pick it despite friction there if the core product is good enough. Capabilities in this category are strong buy candidates almost regardless of cost comparison, because engineering time spent building a merely-adequate version of something a vendor already does well is time not spent on what actually differentiates the product. Conversely, if the capability is core to why customers choose you — the actual recommendation engine, the actual pricing logic, the actual workflow that competitors can't replicate — building it in-house is usually correct even when a vendor product looks cheaper on paper, because you can't outsource your differentiation and expect to keep it.

What does the integration surface actually cost over five years, not one

The second question is the integration and exit cost, evaluated over a multi-year horizon, not the first-year implementation cost vendors quote. We look specifically at three things: how deeply the vendor's data model gets woven into your own schema (a vendor that becomes your system of record for a core entity is far more expensive to leave than one that's a peripheral integration), whether the vendor's API supports a clean data export in a format you could actually migrate from, and what happens to your product if the vendor has an extended outage — is it a degraded experience or a full stop. A vendor that's cheap today but becomes your system of record for customer data without a credible export path is a build-vs-buy decision you'll be forced to revisit in a worse negotiating position three years from now, during a renewal, rather than on your own timeline.

The "build a thin wrapper" middle path is usually correct

The false dichotomy in most build-vs-buy discussions is that you either fully build or fully adopt the vendor's model throughout your codebase. The approach that holds up best in practice is a third option: buy the capability, but build a thin abstraction layer between the vendor's API and the rest of your system, so that your application code depends on your own interface, not the vendor's specific shape. This costs a modest amount of extra engineering up front and pays for itself the moment you need to switch vendors, add a second vendor for redundancy, or negotiate pricing with a credible alternative already partially integrated. We treat this wrapper as close to mandatory for any vendor handling a capability with meaningful switching risk — payments, auth, and messaging chief among them — even when the team's instinct is to move fast and integrate directly.

Revisit the decision on a schedule, not just under duress

Build-vs-buy is usually decided once, at the moment a capability is first needed, and then never revisited until a vendor relationship becomes painful enough to force the question. We put an explicit revisit trigger on every buy decision at the time it's made — a specific scale threshold, a specific pricing tier, a specific contract renewal date — so that the next evaluation happens on the team's own terms, with time to execute a migration carefully, rather than during a renewal negotiation where the vendor holds most of the leverage because switching under deadline pressure is expensive and risky.

The framework isn't a formula that spits out an answer — it's a way of making sure the actual cost drivers, differentiation and exit cost, get weighed before the license quote does.