Build-vs-Buy & Platform Thinking

⏱ ~10 min read · 🎧 9 min listen · ✎ 3 quizzes · 🧪 ~45 min lab

Lesson 10 gave you the strategy kernel: diagnosis, guiding policy, coherent action. This lesson is where the kernel meets a purchase order. Build-vs-buy calls and platform investments are the two places a company's real technical strategy shows — not the one in the deck, the one in the payroll. A build-vs-buy memo is a mini strategy document: a diagnosis of what actually differentiates the business, a policy about where engineers are spent, and one concrete action.³ Principals get asked to write these precisely because the answer is never in a cost spreadsheet.

The first cut: core vs context

Geoffrey Moore's distinction does most of the work. Core is any activity that creates differentiation customers will pay for — it's why they pick you over the competitor. Context is everything else: work you must do competently to be a legitimate player, but that no customer will ever reward you for doing better than the market standard.¹ The core-vs-context test for build-vs-buy follows directly: build what differentiates the business; buy everything else. Every engineer-hour spent polishing context is an hour extracted from core.¹

The test bites harder than it sounds, because engineers systematically misfile interesting as core. Your own auth system, your own feature flags, your own job scheduler — all fascinating to build, almost never what customers choose you for. Ask the business question, not the engineering one: "if ours were twice as good as the vendor's, would we win a single extra customer?" If no, it's context.¹ And note the arrow of time: what's core today commoditizes into context tomorrow, so the verdict has an expiry date — Moore's point is that companies must keep pulling resources out of context to reinvest in core.¹

The honest ledger: total cost of ownership

Core-vs-context gives the verdict; total cost of ownership stress-tests it. Most build-vs-buy spreadsheets compare a vendor's sticker price against the engineering weeks to reach v1 — and both numbers are the smallest items on their respective ledgers.⁶ This is a trade-off table exactly like Lesson 2 taught, and the Principal move is the same: surface the costs each side is quietly hiding. Build with the same eyes you'd use on a rival's design review:

Which door is it? Reversibility

The third lens comes from Jeff Bezos's 2015 shareholder letter. Some decisions are one-way doors: consequential and nearly irreversible, so they deserve slow, deliberate scrutiny. Most decisions are two-way doors: if you dislike what's on the other side, you walk back through — and treating those with heavyweight process produces "slowness, unthoughtful risk aversion, failure to experiment sufficiently."² Here's the Principal-level insight: in build-vs-buy, which door you're facing is often your own design choice. A vendor consumed behind a thin interface you own is a two-way door; the same vendor's SDK woven through your business logic is a one-way door with the same monthly bill. Classify the door before you argue the decision — and where it's cheap, spend a little design effort converting one-way into two-way.²

Platform thinking: when shared infrastructure pays

Build-vs-buy's sibling question is "should we build this once, for everyone?" The old reuse research gives the honest starting point — Robert Glass's rules of three: a reusable component costs roughly three times as much as a single-use one, and you don't know it's genuinely general until it has survived three different consumers.⁵ Translated to platforms: don't build shared infrastructure from a prediction. Wait for the repeated need — two or three teams solving the same problem independently — then extract the platform from what they actually built, rather than architecting it in advance for users who don't exist yet.⁵

When you do build one, the operating model matters as much as the code. Evan Bottcher's definition on martinfowler.com is the industry's reference point: a digital platform is "a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product."⁴ Every word is load-bearing. Self-service, because forcing teams to file tickets recreates the queueing the platform was meant to kill. Product, because your internal customers have an alternative — building their own — and a mandate can force usage but never enthusiasm. A platform is compelling when consuming it is easier than building and maintaining your own thing; a platform nobody voluntarily adopts is a failed product with a captive audience.⁴

Which names the classic staff+ failure mode: the platform tax. Premature platformization looks like leverage — "solve it once for the whole org!" — and is usually its opposite: you pay Glass's 3x build cost up front, staff a team to maintain it forever, and slow every product team down with an abstraction designed before its real requirements existed.⁵ It's seductive at exactly your career stage, because a platform looks like scope. Promotion committees have seen that movie; what reads as Principal-level judgment is knowing when not to build one — and saying so in writing.⁴

🧪 Lab: the one-page build-vs-buy memo

Pick a real build-vs-buy decision at your company — one that's live, recent, or plausibly next (a feature-flag service, a workflow engine, an internal ML platform, a vendor renewal). Write a one-page memo — this is the strategy-kernel muscle from Lesson 10 applied at decision scale, and it's a premium promotion-packet artifact:

1. Verdict: core or context — one sentence of business reasoning: would customers pick us over a competitor because ours is better?
2. TCO table — build vs buy, and it must include a row for opportunity cost (what the team won't build) and a row for on-call (who carries the pager, forever).
3. Reversibility — classify the door, and say what design choice (an interface you own, an exit plan) would convert one-way into two-way.
4. Recommendation — with its biggest risk stated plainly, and one explicit line: "as a consequence, we will NOT build ___."

Feedback loop: bring the memo back to me in chat. I'll review it against a Principal-level rubric — does opportunity cost appear explicitly with a name, not a platitude; does the memo say what the team will not build as a consequence; and does the recommendation survive if its riskiest named assumption breaks. Keep it — Lesson 12 slots this straight into your promotion packet as evidence you align technology spend with business strategy.

You are a seasoned Principal Engineer reviewing my work: a one-page build-vs-buy decision memo. Review it against this rubric:

- Core vs context verdict: rests on business reasoning — would customers pick us over a competitor because ours is better? — not on what is interesting to build.
- TCO table: compares build vs buy honestly, and opportunity cost appears explicitly with a name (the specific work the team won't do), not a platitude; on-call ownership is named, forever, not just to v1.
- Reversibility: the decision is classified as a one-way or two-way door, with a design choice (an interface we own, an exit plan) that would convert one-way into two-way.
- Exclusion: the memo states plainly what the team will NOT build as a consequence.
- Robustness: the recommendation survives if its riskiest named assumption breaks.

Grade each criterion Strong / Adequate / Missing, with one sentence of evidence per grade. Be skeptical — challenge the weakest claim first. Then ask me 2–3 follow-up questions a CTO deciding whether to fund this would ask. Finish with the single highest-leverage improvement.

My build-vs-buy memo follows below.

Check yourself — make the call

Three scenarios. Apply the three questions — don't scroll up. Wrong picks stay live.