Build vs Buy Evaluation
The Real Decision Framework: Core vs Context
The single most useful mental model for build-vs-buy decisions comes from Geoffrey Moore's concept of core vs context. Core is what makes your business unique. Context is everything else you need to operate but that doesn't differentiate you. The rule is simple: invest in core, outsource context.
If you're Stripe, your payment processing infrastructure is core. Build it. If you're a food delivery app, payment processing is context. Buy it. This sounds obvious, but teams get it wrong constantly. Engineers love building things. That's the job. But staff engineers need to channel that energy toward the problems that actually matter for the business.
In an interview, start by asking: "Is this capability something our customers choose us for, or is it something we need in order to operate?" That question alone will clarify 80% of build-vs-buy decisions.
Total Cost of Ownership: Doing the Math
When you evaluate build vs buy in an interview, show that you can do a real cost comparison. Here's the framework:
Buy costs: License or subscription fees, integration engineering (typically 2-4 weeks), ongoing vendor management, training, and the risk premium for vendor lock-in and potential price increases.
Build costs: Initial development (engineers x months x fully-loaded cost), ongoing maintenance (typically 20-30% of initial build cost per year), on-call burden, documentation and onboarding for new team members, feature development to keep pace with evolving requirements, and the opportunity cost of what those engineers could have built instead.
Run the numbers over a 3-year horizon. In most cases, building costs 3-5x more than the vendor's sticker price suggests. The interviewer wants to see you do this calculation, not just wave at it vaguely.
When Building Is Actually the Right Call
Building isn't always wrong. Here are the situations where it makes sense:
-
The capability is a genuine differentiator. If your custom solution gives you a competitive advantage that no vendor can match, build it. But be honest about whether it's truly a differentiator or just something your team thinks is cool.
-
No vendor meets your actual requirements. Sometimes the market hasn't caught up to your needs. If you're operating at a scale or with constraints that existing solutions can't handle, building may be your only option. But verify this by actually evaluating vendors, not by assuming.
-
Vendor risk is unacceptable. If a vendor going down or changing their pricing would be catastrophic to your business, the control you get from building in-house may be worth the cost. This is rare, but it's real for critical-path systems.
-
The build scope is genuinely small. A thin wrapper around an existing library is different from building a full platform. If the build is a week of work and the maintenance burden is minimal, the overhead of vendor management might not be worth it.
Evaluating Vendor Health and Risk
When you do choose to buy, the evaluation doesn't stop at features and pricing. You need to assess the vendor itself:
- Financial stability - Is this a funded startup that might disappear, or an established company? Check funding stage, customer count, and revenue trajectory if available.
- Integration depth - How deeply will this vendor's API or data format embed itself in your systems? Can you put an abstraction layer in front of it?
- Exit strategy - Before signing, understand what migration looks like. Can you export your data? Is there an open standard you can target? What's the realistic timeline to switch if you need to?
- Pricing trajectory - What happens to your costs as you scale? Some vendors have pricing models that are friendly at your current size but punishing at 10x. Model the costs at your expected scale in 2-3 years.
Sample Questions
Your team wants to build an internal feature flag system. A commercial option exists at $50K/year. How do you decide?
The interviewer wants to see total cost of ownership analysis, not just a comparison of sticker prices. Factor in engineering time to build, ongoing maintenance, on-call burden, opportunity cost of not working on product features, and the risk of building something that falls behind commercial offerings over time.
You adopted a vendor 2 years ago and it's not working. Walk me through your evaluation for a replacement.
This tests whether you can reason about sunk cost, migration cost, and switching criteria. They want to see a structured evaluation framework, not just frustration with the current vendor. Show that you can separate 'this isn't working' from 'something else would be better.'
How do you evaluate open-source vs managed service vs building from scratch?
Each option has different implications for maintenance burden, control, and organizational capability. The interviewer wants to see you reason about your team's ability to operate what they choose, not just the technical merits of each option.
Evaluation Criteria
- Evaluates total cost of ownership including hidden costs like maintenance, on-call, and opportunity cost
- Identifies whether the capability is a core differentiator or commodity infrastructure
- Assesses the organization's realistic ability to build and maintain the solution long-term
- Plans for vendor risk including lock-in, pricing changes, and vendor viability
- Frames decisions in terms of reversibility and makes appropriately cautious choices for irreversible ones
Key Points
- •Total cost of ownership is the real number. A $50K/year vendor looks expensive until you calculate that building in-house costs 2 engineers for 6 months plus ongoing maintenance. That's $300K+ in the first year alone, and the cost never goes to zero.
- •Ask yourself: is this a differentiator? If feature flags aren't what makes your product special, buying is almost always right. Save your engineering capacity for the things that actually set you apart from competitors.
- •Vendor lock-in exists on a spectrum. Switching a logging provider is annoying but doable in a quarter. Switching a database is a multi-year project. Assess lock-in risk before you commit, and design integration layers where the switching cost is high.
- •The hidden cost of building is real and ongoing. You don't just build it once. You maintain it, fix bugs, handle security patches, write documentation, train new hires on it, and carry the on-call burden forever. Most teams dramatically underestimate this.
- •Decision reversibility should influence your process. A reversible decision (trying a new CI tool) deserves a quick evaluation and a 30-day trial. An irreversible decision (choosing a primary database) deserves weeks of analysis and a formal RFC.
Common Mistakes
- ✗Comparing build cost to the vendor's sticker price while ignoring maintenance, on-call, documentation, and opportunity cost. The sticker price is the smallest part of the buy cost, and the build cost is the smallest part of the build cost.
- ✗Assuming you can always switch later. Migration costs are almost always higher than you expect, and 'temporary' vendor choices have a way of becoming permanent. Decide as if you'll be living with this choice for 5 years.
- ✗Building because 'we can do it better.' Maybe you can. But should you? Every hour your team spends building commodity infrastructure is an hour they're not spending on your actual product.
- ✗Not evaluating the team's ability to maintain what they build. A team of 4 engineers can build an impressive feature flag system in a quarter. That same team cannot maintain a feature flag system, a deployment pipeline, a monitoring stack, and their actual product simultaneously.