The Tech Lead Handbook · Technical Decisions
Build vs Buy
A structured way to decide whether to build a capability or use a vendor or open-source product, including the costs that are usually forgotten.
Scenario
Example team: the payments team needs feature flags. One engineer says "it's a key-value lookup, we'll build it in two days". Eighteen months later the in-house flag service has an admin UI, audit logging, percentage rollouts and a part-time maintainer — and still no targeting by customer segment.
What you see on the team
- Internal tools that started small and became products nobody planned to maintain.
- Or the opposite: vendors adopted without checking data residency, pricing at scale, or exit costs.
- Estimates that compare "two days to build" with "a yearly licence", ignoring everything else.
The common mistake
Comparing build effort with purchase price, and ignoring the total cost of ownership and the strategic question: is this capability core to what makes us different?
Why it happens
Building feels cheaper because engineering time is already paid for and the first version is genuinely quick. The costs come later: maintenance, on-call, features users ask for, security reviews, the knowledge leaving with the builder. Buying feels risky because the costs are explicit and contractual.
The playbook
1. Ask the strategic question first. Is this capability part of what differentiates the product? Payments reconciliation logic might be; feature flags, auth, email delivery and observability usually aren't.
2. Compare total cost over three years, not the first version:
| Cost | Build | Buy |
|---|---|---|
| Initial | Design and implementation | Integration, migration, procurement |
| Ongoing | Maintenance, on-call, upgrades, security fixes, features users request | Licence growth with usage, vendor management |
| Hidden | Knowledge concentration, opportunity cost of the team | Lock-in, exit migration, data residency, vendor outages |
3. Check the non-negotiables: security and compliance, data location, SLA, pricing at 10x scale, API quality, exit path (can you export your data?).
4. Prefer "buy and wrap" for non-core capabilities: put a thin internal interface in front of the vendor, so switching later is a contained change.
5. Record the decision in an ADR with the assumptions (usage, price) and a revisit trigger.
What to say
Framing the discussion:
"Before we estimate the build, is feature flagging something that makes our product different? If not, let's compare three-year cost, including on-call and the features we'll be asked for, against two vendors — and check data residency and pricing at our 2028 traffic."
Trade-offs
- Buying saves engineering time but adds vendor risk and recurring cost; wrap it to keep options open.
- Building gives control and fit, but only pays off when the capability is core or the market has nothing suitable.
- Open source sits in between: no licence cost, but you own upgrades, security patches and operations.
Signals it's working
- Build decisions name who will maintain the system and how much time it gets.
- Vendor decisions have an exit plan and an internal interface.
- Three-year cost estimates are revisited and roughly hold.
- The team spends most of its time on differentiating work.
Key points
- Start with strategy: build what differentiates you, buy what doesn't.
- Compare three-year total cost of ownership, including maintenance, on-call and opportunity cost.
- Check non-negotiables: security, data location, SLA, pricing at scale, exit path.
- Prefer "buy and wrap" for non-core capabilities; record the decision in an ADR.
Practice questions
An engineer says the in-house feature-flag service will take two days. What's missing from that estimate?
Answer
Everything after version one: admin UI, audit, targeting and rollouts users will ask for, on-call, upgrades and security fixes, and the opportunity cost of the team — compared over three years against vendor cost, integration and exit risk.
Which capabilities are usually good candidates to buy rather than build?
Answer
Non-differentiating ones: authentication, feature flags, email/SMS delivery, observability, CI. Build what makes the product different, such as core domain logic.
What does 'buy and wrap' mean and why do it?
Answer
Use a vendor behind a thin internal interface owned by your team. It keeps vendor-specific code in one place, so a later switch (price, outage, compliance) is a contained change rather than a rewrite.
Open in the app to mark lessons complete, take notes and track your progress.