Vendor vs. build for a core component
The technical and organizational framework for evaluating build vs. buy decisions — when buying is correct, when you must build, and how to present the case either way.
The Strategic Question
"Should we build this ourselves or buy it?" is one of the questions that defines what kind of company you're building. Every component you build is a component you maintain, on-call for, and hire to support. Every component you buy is a vendor relationship you manage and a dependency you can't fully control.
The right answer depends on where this component sits: is it in your core competency or not?
The Make vs. Buy Framework
Axis 1: Commodity vs. Differentiator
│ Generic capability │ Your differentiation
────────────────────┼────────────────────────┼──────────────────────────
Build │ Almost never right │ Often right
Buy / Open Source │ Almost always right │ Risky
If the capability is generic infrastructure — auth, email delivery, payments, monitoring, search — you should strongly prefer buying or using managed services. Your competitors have access to the same infrastructure. The advantage comes from what you build on top of it.
If the capability is your product differentiation — recommendation engine, pricing model, fraud detection, core matching algorithm — buying forces you to accept someone else's model, and that model is available to every competitor too.
Axis 2: The build cost is never the sticker price
Total ownership cost of building:
- Initial implementation (you see this)
- Test suite maintenance (often equal to implementation)
- On-call: alerts, runbooks, incident response
- Feature requests from adjacent teams
- Keeping up with ecosystem changes
- Knowledge loss when the original author leaves
- Migration cost if you get it wrong and need to replace it
A rule of thumb: operational cost over 3 years is 2-3x the initial build cost. Your estimate should include this.
Axis 3: The vendor has lock-in; so does the custom build
Engineers often prefer building because it avoids vendor lock-in. But a custom system is its own form of lock-in: lock-in to the architectural decisions made when it was written, the specific capability set it was built with, and the team that understands it.
The relevant question isn't "will I be locked in?" — you will be, either way. The question is "which lock-in is more aligned with where we want to go in 3 years?"
When Vendor Is Correct
Signal 1: You can describe the requirement in 3 sentences.
If you can completely describe what you need that briefly, someone has
already built and productized it. You do not need to build it.
Signal 2: There are 5+ mature vendors in this category.
Competitive vendor market = commodity. Your job is vendor selection and
negotiation, not engineering.
Signal 3: The initial requirement came from a compliance need.
SOC2, GDPR, HIPAA, PCI compliance requirements are met by established
vendor tooling. The compliance bodies have approved those tools.
Building your own is a harder compliance path, not an easier one.
When Building Is Justified
Signal 1: No vendor's model matches your data model or constraints.
Example: your ML model for pricing requires real-time features that no
vendor can compute from your source data. No vendor integrates with your
event stream. You must build the feature computation layer.
Signal 2: Vendor pricing would be prohibitive at your scale.
Some SaaS products are priced per event or per seat in ways that become
uneconomical past a certain scale point. The build threshold depends on
your growth trajectory.
Signal 3: The vendor would receive sensitive data you can't share.
PII, financial data, health data — regulatory constraints sometimes
mean you cannot send data to a third-party vendor even if the vendor's
capability would otherwise be the right choice.
Signal 4: The feature IS the product.
If the vendor's algorithm is what you'd be selling to your customers,
you have no defensible proprietary capability.
The Evaluation Process
When you need to make this decision formally:
-
Write the requirement precisely. Vague requirements favor building (custom = fits anything). Precise requirements favor buying (easier to evaluate vendor fit).
-
Map the top 3 vendors. Spend 2-4 hours on each: pricing, integration complexity, feature coverage, SLA, data handling, support.
-
Build a PoC with the leading vendor candidate. Integration complexity is almost always underestimated in the sales call. Running the integration yourself surfaces hidden costs.
-
Estimate the build cost honestly. Include test suite, operational model, on-call runbook, and 3-year maintenance. If you can't estimate this, you haven't scoped it well enough to build.
-
Total cost of ownership comparison: vendor 3-year cost vs. build 3-year cost. The build almost always has a higher TCO — you need a strategic reason to choose it anyway.
Story Structure
Context (30s): What was the component, what were the options, why was this a real decision?
Your analysis (2 min): What was the evaluation process? What data did you gather? What did the PoC reveal?
The decision (1 min): What was the recommendation? Who was skeptical, and what was their concern?
Outcome (30s): How did it go? What would you change in hindsight?
Common Interview Anti-Patterns
| Answer | What it signals |
|---|---|
| "We built it ourselves because vendors are a black box" | Reflexive NIH syndrome; no cost accounting |
| "We always use managed services" | No strategic thinking about differentiation |
| "I estimated the build would take 2 weeks" | No operational cost accounting; naive estimate |
| "The vendor was expensive but we used them anyway" | No ROI evaluation |
The strong answer includes a TCO comparison, a PoC, and a clear articulation of why this was or wasn't differentiating.
Quick Recap
- The core question is commodity vs. differentiator — generic infrastructure should be bought; core differentiation should be built.
- Build cost is not the sticker price: include test suites, on-call, maintenance, and the migration cost if you get it wrong.
- Both vendor and custom builds create lock-in; pick the lock-in that aligns with your 3-year direction.
- Build a PoC with the leading vendor candidate — integration complexity is always underestimated in the sales call.
- A build is justified when: no vendor model fits your constraints, vendor pricing is uneconomical at scale, regulatory restrictions prevent data sharing, or the feature IS your product's differentiator.