Evaluating Build vs Buy

Every team faces the choice between building a capability and buying it, whether that is authentication, search, billing, or a data pipeline. The decision is often made on gut feeling: engineers prefer building, finance prefers the lower sticker price. A structured evaluation produces better outcomes and a record that explains the choice later.

Start with differentiation

Ask whether the capability gives you a competitive advantage. If customers choose you because of it, build it, or at least own the core. If it is table stakes, buy it.

| Capability | Differentiating? | Default lean | |------------|------------------|--------------| | Recommendation engine at a streaming company | Yes | Build | | Authentication at a logistics company | No | Buy | | Payment processing at most companies | No | Buy | | Pricing algorithm at a marketplace | Yes | Build |

The same capability can flip: email delivery is commodity for a retailer and the core product for an email marketing company.

Compare total cost of ownership

Initial build cost is the smallest part of a built system. Include:

• Build: engineer time, design, security review, testing.
• Run: infrastructure, on-call, upgrades, incident response.
• Change: continuous feature work, compliance updates, scaling.
• Opportunity: what those engineers would otherwise ship.

For buying, include license or usage fees at projected scale, integration effort, vendor management, training, and customization.

Three-year view, auth service
Build: 4 engineers x 6 months + 1.5 engineers ongoing = about 1.1M
Buy:   usage fees at 500k users = about 450k + 2 months integration
Break-even: only if we exceed several million users or need unique flows

Usage-based pricing can flip the math at scale, so model growth, not just today.

Assess fit and risk

Score candidates against your actual requirements, not a feature checklist. Weight must-haves, and treat gaps honestly: a vendor that covers 85 percent of needs leaves 15 percent that will be painful workarounds. Then examine risk.

| Risk | Questions to ask | |------|------------------| | Lock-in | How hard is data export? Are interfaces proprietary? | | Vendor viability | Financial health, customer base, acquisition likelihood | | Security and compliance | Certifications, data residency, audit rights | | Roadmap control | Can we influence priorities, or are we a small customer? | | Reliability | Published SLA, incident history, support quality |

Prove it with a spike

Before committing, run a time-boxed proof of concept against your hardest requirement, not the demo path. One to two weeks of integration will reveal rate limits, awkward APIs, and missing edge cases that no sales call mentions. Do the same for a built option: prototype the part you are least sure about.

Reduce lock-in by design

Whatever you choose, isolate it. Wrap vendor APIs behind your own interface so replacement means changing one adapter, not the whole system. Keep your own copy of critical data. Negotiate exit terms and data export rights in the contract. For a built system, document it well enough that the next team can maintain it.

Plan the exit and review the decision

Write down the conditions under which you would reverse the choice: "If vendor costs exceed 300k per year, or if we need a workflow they cannot support, we reevaluate building." Revisit after twelve months with actual cost and satisfaction data. Many teams discover a build decision has become a maintenance burden, or that a bought tool has been outgrown.

Capture the decision in a short record: options considered, criteria, scores, assumptions, and the trigger for review.

Key takeaways

• Build what differentiates you; buy what is commodity.
• Compare total cost over three years, including run, change, and opportunity cost.
• Test the hardest requirement with a time-boxed spike.
• Isolate vendors behind interfaces and secure data export rights.
• Define exit triggers and review the decision after a year.