decision making

The Build vs. Buy Decision Framework: When to Own vs. When to Integrate

A systematic framework for deciding whether to build, buy, or integrate third-party solutions based on strategic advantage and cost.

Timoté Geimer · · 14 min read

The Core Answer

Build when the capability is a source of defensible differentiation and the total cost of ownership (engineering + maintenance + opportunity cost) is lower than buying or integrating. Buy when the capability is table-stakes, the market solution is mature, and the switching cost is low. The actual decision hinges on three questions: (1) Is this a source of competitive advantage or just table-stakes? (2) What’s the true 3-year cost including engineering, maintenance, and opportunity cost? (3) How fast do we need it versus how fast can we build it? Most PMs get this wrong by underestimating the cost of building (it’s never just the initial implementation) or overestimating the switching cost of buying (it’s usually lower than you think).

The Mistake: False Economies of Building

Building in-house feels cheaper upfront. The engineering team estimates 4 weeks, management approves, and six months later you’ve shipped something that requires ongoing maintenance, bug fixes, and eventually a rewrite. You’ve now spent 12+ engineer-weeks and created a technical dependency.

Meanwhile, there’s a third-party solution that would have taken 2 weeks to integrate, costs $500/month, and is maintained by a vendor with 50 engineers. You saved zero dollars. You spent more engineering time, created maintenance burden, and now you’re slower to market because you built instead of bought.

The calculation most PMs miss is the denominator: it’s not “cost to build once.” It’s “cost to build, maintain, and eventually replace.” The numerator of buying is transparent—there’s a price tag. The numerator of building is hidden across a dozen quarters and a dozen code reviews.

The Three-Lever Decision Matrix

Lever 1: Competitive Advantage Test

Ask: Does this capability make our product different? Can a customer not get this anywhere else? Will losing this capability meaningfully reduce our competitive position?

If the answer is yes to all three, build. If the answer is no to any of them, don’t.

Examples of build:

  • Your core algorithm (if it’s truly proprietary)
  • Your data model (how you uniquely structure information your competitors don’t)
  • Your user experience (if your interface is what people choose you for)

Examples of buy or integrate:

  • Authentication
  • Payment processing
  • Basic analytics
  • Email delivery
  • Search infrastructure
  • Hosting

Lever 2: Total Cost of Ownership Calculation

Build the honest spreadsheet. Don’t estimate the initial engineering. Estimate:

  • Build cost: Time to implement + time to test + time to ship
  • Maintenance cost: 15-25% of build cost annually (bug fixes, dependency updates, refactoring)
  • Opportunity cost: What else would those engineers be working on? If they’d be building revenue-generating features, assign that value
  • Replacement cost: In 3 years, you’ll want to rewrite this or migrate to a better solution. Build that cost in

Compare to buying:

  • License/SaaS cost: Annual subscription or per-unit pricing
  • Integration cost: Time to integrate API, set up data pipelines, configure
  • Switching cost: How hard is it to migrate to a different vendor in 2 years? (Usually lower than you think)

Do the honest math. If you’re building a feature that costs 10 engineer-weeks plus ongoing maintenance, but buying costs $2k/month, the buy wins unless you’re building something genuinely differentiated.

Lever 3: Speed to Market vs. Speed of Execution

How urgently do you need this capability? If you need it in 4 weeks, buying is faster. If you have 6 months and the market is moving slower than you can build, building might be defensible.

But be honest about your execution speed. If your team takes 12 weeks to ship anything, buying is faster. If your team consistently ships in 2 weeks, the math favors building slightly, but only if you’re also solving for (1) and (2).

The worst case is: slow execution + table-stakes capability + high switching cost. Don’t build. Ever.

The Integration Hybrid: When You Buy Core, Build on Top

Most mature products use a hybrid approach: buy the commodity infrastructure, build the differentiator on top.

Example: You buy a data warehouse (Snowflake) but build your proprietary analysis layer. You buy a CRM platform (Salesforce) but build the custom workflows that drive your sales process. You buy a search engine (Elasticsearch) but build the ranking algorithm that makes it unique.

This wins on all three levers:

  • You buy to remove maintenance burden and table-stakes work
  • You build only where you differentiate
  • You move faster by not reinventing databases, but slower only where it matters

Common Mistakes That Sink Decisions

Mistake 1: Confusing “We Built It” with “We Own It”

Just because your engineers built something doesn’t mean you’ve reduced dependency. If the system is fragile, poorly documented, and requires deep knowledge to maintain, you own more risk, not less.

Mistake 2: Underestimating Switching Costs

You think migrating from Vendor A to Vendor B will take 6 months. In reality, it takes 2 months plus a month of operational problems. Switching cost is real but usually lower than the cost of building in the first place.

Mistake 3: Overweighting “Full Control”

You want to build because “we’ll have full control.” You do, and it’s a burden. You now have to update the payment library when the new API spec arrives. You have to fix bugs in your authentication system. You now own production risk for something that could have been someone else’s problem.

Mistake 4: Comparing Today’s Cost to Tomorrow’s Requirements

You build something for today’s use case, then requirements change. Now you’re maintaining something that doesn’t fit what you actually need. Third-party solutions evolve. Your built solution has to be manually rewritten.

How to Apply This Framework

Step 1: Identify the Capability

What specifically are you considering? Be precise. Don’t ask “should we build or buy a CRM?” Ask “should we build or buy a sales pipeline management system?”

Step 2: Run the Competitive Advantage Test

Does this differentiate you? Will customers choose you specifically for this? Can competitors not get this elsewhere? Write a one-sentence answer to each question.

Step 3: Build the TCO Spreadsheet

Get engineering estimates. Get vendor pricing. Build a 3-year cost model with honest maintenance assumptions. Include opportunity cost of engineer time. Compare the total.

Step 4: Pressure-Test Your Assumptions

What would have to be true for the other option to win? If you’re building, what if maintenance takes 40% of engineering time instead of 15%? If you’re buying, what if switching costs 50% more than estimated? Run the sensitivity analysis.

Step 5: Make the Call

If build wins on advantage, cost, and speed, build. If buy wins on any two of the three, buy. If they’re equal, buy (lower risk).

The Bottom Line

Build vs. buy is not a technology decision—it’s a capital allocation decision. You’re choosing what to invest engineering capacity in. Build when the investment creates defensible competitive advantage and the total cost is lower than the alternative. Buy when you’re buying table-stakes capability, integration cost is manageable, and you’re freeing engineering to work on what actually differentiates you.

The cost of building is always higher than you estimate upfront, and the cost of buying is always more transparent than you initially think. The discipline is in running the honest math, not defaulting to build because you have engineers or buy because it’s convenient. The right answer depends on your specific competitive position, execution speed, and the capability in question.