Lesson 0027 · Master Designer · Module 1
Build vs Buy
Lesson 0026 gave the developer's version. The Master Designer's version adds the full accounting: licensing, upgrades, vendor risk, and the one question that overrules everything.
Mission tie-in: the first Complexity Trade-Off — where you learn to make decisions under constraints instead of by preference.
Knowledge: the full cost ledger
Both options have costs that are easy to undercount. The discipline is writing both ledgers:
| Build | Buy | |
|---|---|---|
| Visible | Dev time, tests, docs | License, subscription |
| Hidden | Every bug and edge case forever; the team must learn the domain you built | Upgrade cadence, vendor roadmap, contract lock-in, supply-chain surface |
| Control | Total — it's yours | Bounded — you follow their pace |
| Fit | Exactly your problem | Their 80% — you adapt to it |
The overruling question (from lesson 0026, now with the ledger behind it): is this your differentiator? If the thing you're building is the reason customers choose you, build — you cannot outsource the thing that makes you you. If it's plumbing — identity, billing infrastructure, file storage, a data-grid component — buy, and spend your team on the differentiator instead.
The third option, often missed: buy the boring 80% and build the 20% that matters. A vendor library + your adapter (lesson 0026's wrap rule) is usually the honest middle: their maturity, your edge.
The middle path has a shape, and it is the port from lesson 0009:
# your 20%: the workflow vocabulary, owned by you
class SignatureService(Protocol):
def request(self, doc: Document, signer: Party) -> RequestId: ...
def status(self, request: RequestId) -> SignatureStatus: ...
# their 80%: maturity, contained behind the port
class VendorSignatureAdapter:
def __init__(self, client: VendorSDK) -> None:
self._client = client
def request(self, doc: Document, signer: Party) -> RequestId:
envelope = self._client.envelopes.create(...) # their words stop here
return RequestId(envelope.id)The port is the boundary of the purchase. Everything the vendor is genuinely good at lives on one side; everything that makes the workflow yours lives on the other. When their v3 renames envelopes to agreements, exactly one file changes — and the upgrade tax stops being a project.
A ledger with numbers in it (illustrative)
Document signing, sized by one team at a loaded rate of €90/hour:
- Build: 400 h to first release (€36,000), then ~80 h/year of maintenance and edge cases (€7,200/yr) — plus a legal review of signature validity that nobody on the team is qualified to sign off.
- Buy: €1,500/month licence (€18,000/yr), 16 h for the adapter (€1,440, once), ~8 h/year of upgrade tax (€720/yr).
| Cumulative | Year 1 | Year 2 | Year 3 | Year 4 |
|---|---|---|---|---|
| Build | €43,200 | €50,400 | €57,600 | €64,800 |
| Buy | €20,160 | €38,880 | €57,600 | €76,320 |
Break-even lands in year three. That single number reframes the argument: below a three-year horizon the ledger says buy and it is not close; above it, buying is a subscription you keep renewing. Teams argue for months about build vs buy without ever writing the two columns that make the horizon visible.
And notice what the ledger still does not settle. If signing were the product, you would pay the €43,200 in year one and call it the cost of owning your edge. If it is plumbing, the year-four crossover is an argument for renegotiating the licence, not for writing an e-signature stack. The ledger sizes the decision; the differentiator test makes it.
| Ask | Build if… | Buy if… |
|---|---|---|
| Is this why customers choose us? | yes — it is the edge | no — it is plumbing |
| Would a bug here be a breach or a lawsuit? | only with a real security budget | yes — you are buying the liability too |
| How fast does this part of our domain move? | faster than any vendor ships | slower than the vendor’s roadmap |
| Can we leave in a quarter if we must? | always — it is yours | only if there is an export path in the contract |
| Who is paged at 3 a.m. when it breaks? | your team, forever | still your team — vendors don’t take your pager |
Skill: which ledger wins?
Your startup's product is its recommendation engine. You should:
A billing system with vendor support and an API is best treated as:
The most undercounted cost in "buy" is:
Practice on your own code
Pick a system component you're about to build or buy (or already built). Write both ledgers — visible and hidden — for each option. Then state, in one sentence, why the differentiator test lands where it does.
Reveal: a worked ledger
A team needed document signing. Vendor option: mature e-signature SaaS (license + their API). Build option: 400 hours + legal review of signature validity. The differentiator test: signing is plumbing — customers buy the workflow, not the signature. Buy. The adapter around the vendor's API took two days, and the workflow team stayed on the workflow.
Your win
You can write the full cost ledger for build vs buy, apply the differentiator test that overrules the ledger, and recognize the 80/20 middle path.
Read and watch deeper
- "Choose Boring Technology", Dan McKinley — the buying-side posture, upgrade tax included.
- "Simple Made Easy", Hickey — the cost-of-complexity frame that makes the ledger honest.
- Software Architecture in Practice, Bass et al. — the quality-attribute trade-off analysis (ATAM) this ledger is a small version of.
- Watch: ArjanCodes YouTube — search "build vs buy".
- Next: lesson 0028 — Abstraction vs Duplication.
- Reference: Trade-offs — build vs buy, including the signal that you chose wrong.
Run your real ledger past your agent-teacher and let it poke the hidden columns.