The Build vs Buy Decision Framework

I've watched engineering teams waste over $2M building internal tools they should've bought off the shelf. I've also watched them spend $800K/year on vendor licenses for software a junior dev could've built in two sprints. The build vs buy decision is the most expensive recurring judgment call an engineering leader makes, and most teams get it wrong because they rely on gut feel instead of a repeatable framework.

Over 11 years leading engineering orgs, I've evaluated 130+ build vs buy decisions. 38 of those were wrong calls that I either made or inherited. This post is the framework I use now, and it's saved my last three teams from at least $500K in misallocated spend per year.

# Why Most Build vs Buy Analyses Fail

The standard approach looks like this: someone puts together a spreadsheet comparing vendor costs against estimated development time. The spreadsheet always lies. Here's why.

Building costs are underestimated by 2.5-4x. A 2024 study from Stripe's developer tools team found that internal tooling projects exceed initial estimates by an average of 2.7x. I've tracked my own teams' estimates against actuals across 43 projects, and the median overrun was 3.1x.

Buying costs are underestimated differently. Teams calculate the license fee and stop there. They forget integration costs, migration costs, training costs, the cost of workarounds when the vendor doesn't support your exact workflow, and the ongoing tax of keeping a third-party dependency updated.

Both numbers are wrong. But they're wrong in different ways, which means the comparison is meaningless.

# The CORE Decision Matrix

I use a four-factor matrix I call CORE: Competitive advantage, Operational complexity, Rate of change, and Ecosystem fit. Score each factor 1-5, then the math tells you what to do.

# Factor 1: Competitive Advantage (Weight: 3x)

Ask this question: "If our competitor had the exact same version of this software, would it matter?"

• Score 5: This is your product. Building it IS the business.
• Score 4: Directly differentiates your product in ways customers notice.
• Score 3: Indirectly supports differentiation. Customers don't see it, but it affects speed or quality.
• Score 2: Useful internally but doesn't touch the product experience.
• Score 1: Pure commodity. Authentication, email sending, payment processing for non-fintech companies.

If it scores 1-2 on competitive advantage, stop analyzing. Buy it. I don't care what the other factors say. Building commodity infrastructure is the single most common way engineering teams destroy value.

# Factor 2: Operational Complexity (Weight: 2x)

How hard is this thing to keep running after you build it?

• Score 5: Requires dedicated on-call, specialized knowledge, and constant attention. Think database engines or real-time messaging infrastructure.
• Score 4: Needs regular maintenance, security patching, and performance tuning. Think internal auth systems.
• Score 3: Moderate maintenance. Quarterly updates, occasional bug fixes.
• Score 2: Set-and-forget after initial build. Minor updates annually.
• Score 1: Truly static. Build once, runs forever.

High operational complexity scores push toward buying because vendors amortize that ops burden across thousands of customers. Your three-person platform team can't compete with Datadog's 200-person infrastructure team on keeping a monitoring system reliable.

# Factor 3: Rate of Change (Weight: 2x)

How fast is this domain evolving?

• Score 5: Weekly changes in the underlying technology or standards. AI/ML tooling in 2026 is a perfect example.
• Score 4: Monthly changes. Cloud provider APIs, security compliance requirements.
• Score 3: Quarterly shifts. Front-end frameworks, CI/CD best practices.
• Score 2: Annual changes. REST API conventions, database schemas.
• Score 1: Glacial. TCP/IP isn't changing this decade.

High rate of change pushes toward buying. Vendors track changes because that's their full-time job. Your team has a product to build.

# Factor 4: Ecosystem Fit (Weight: 1x)

How well do available vendor solutions fit your specific tech stack and workflow?

• Score 5: No vendor covers your use case. You'd need to combine 3+ tools and build glue code anyway.
• Score 4: Vendors exist but require significant customization (>20% of the functionality needs custom work).
• Score 3: Good vendor options exist with minor gaps. Standard integration effort.
• Score 2: Multiple strong vendors, well-documented integrations for your stack.
• Score 1: Dominant vendor that's basically an industry standard. Think Stripe for payments.

# Calculating the Score

Build Score = (CompetitiveAdvantage x 3) + (OperationalComplexity x 2)
              + (RateOfChange x 2) + (EcosystemFit x 1)

Maximum possible: 40
Minimum possible: 8

Score interpretation:

• 32-40: Build. This is core to your business and you need full control.
• 24-31: Lean build, but validate with a time-boxed prototype first.
• 16-23: Lean buy, but negotiate hard on customization and API access.
• 8-15: Buy immediately. Every sprint you spend building this is waste.

# The Contrarian Take Most Leaders Miss

Here's where I disagree with conventional wisdom: most build vs buy frameworks treat the decision as permanent. They shouldn't. The right answer changes over time.

I schedule build vs buy re-evaluations every 12 months for anything scoring 16-31. Here's why: a tool you built 3 years ago when no vendor existed might now have 5 strong SaaS competitors. A vendor you chose 2 years ago might have tripled their pricing or degraded their API.

At my last company, we built an internal feature flagging system in 2022 because LaunchDarkly was $48K/year and the alternatives were immature. By 2024, three strong open-source options existed. We migrated to one in 6 weeks and freed up an engineer who'd been spending 15% of their time maintaining our custom system. That's 7.8 weeks of engineering capacity recovered annually.

# Real Decisions I've Made With This Framework

Authentication (Score: 11 - Strong Buy)

• Competitive advantage: 1 (nobody picks your product because of your login screen)
• Operational complexity: 4 (security patches, OAuth updates, MFA standards)
• Rate of change: 4 (passkeys, WebAuthn, constantly shifting)
• Ecosystem fit: 1 (Auth0, Clerk, dozens of options)

We went with Clerk. Total integration time was 3 days. Building equivalent functionality would've taken 8-12 weeks and required ongoing security expertise we didn't have.

Code Analysis Engine (Score: 36 - Strong Build)

• Competitive advantage: 5 (this IS our product)
• Operational complexity: 4 (it's complex, but that complexity is our moat)
• Rate of change: 5 (AI-powered analysis is evolving weekly)
• Ecosystem fit: 5 (nothing on the market does what we need)

We built it. Obviously. But the framework confirmed the instinct with data.

Internal Admin Dashboard (Score: 14 - Strong Buy)

• Competitive advantage: 1 (internal tool, no customer sees it)
• Operational complexity: 2 (pretty stable once built)
• Rate of change: 2 (admin needs change slowly)
• Ecosystem fit: 2 (Retool, Appsmith, multiple strong options)

We bought Retool. My engineering manager wanted to build a custom React dashboard. The CORE score saved us 6 weeks of engineering time.

# The Stealable Framework: 72-Hour Validation Sprint

Before committing to any build decision with a score above 24, run a 72-hour validation sprint. Here's the exact structure:

Hours 0-8: One senior engineer builds the simplest possible version that handles the primary use case.

Hours 8-24: Same engineer extends it to cover the top 3 edge cases identified by the team.

Hours 24-48: A different engineer tries to use, modify, and break it. They document every friction point.

Hours 48-72: The team reviews findings and answers: "Based on this prototype, do we still believe the build estimate? What did we miss?"

In my experience, 40% of build decisions get reversed after the 72-hour sprint. Not because building is wrong, but because the prototype reveals hidden complexity the initial estimate missed. That's $200K+ in avoided waste every time it catches a bad call.

# Applying This to Your Next Decision

Pull up the last three tools your team discussed building. Score each one using CORE. I'd bet at least one of them scores below 16 and should be bought instead.

The goal isn't to never build. The goal is to build the right things. Every sprint spent building commodity infrastructure is a sprint not spent on your actual product. And in 2026, with AI accelerating the pace of change in vendor tools, the buy option is stronger than it's ever been.

Keep the framework somewhere your team can reference it. Make it part of your RFC template. The 5 minutes spent scoring CORE will save you months of wasted engineering effort.