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.

Reading ≈ 9 minPractice ≈ 50 min

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:

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.

Worked example: what the senior looked at before the price

Same document-signing decision, watched over the shoulder of someone who has made it before. They do not open the pricing page first. They ask two questions the ledger cannot answer.

"If this vendor triples the price at renewal, or is acquired and sunset, what do we do on the Monday after?" That is the reversibility question, and it produces a number: sixteen hours to write a second adapter plus roughly forty hours to export and verify the historical signature records — about €5,000, once. A vendor whose exit costs more than a year of licence owns you, whatever the ledger says. Here it does not.

"Which of our twelve workflow steps does the vendor do natively, which need configuration, and which need a workaround?" Ten native, one configured, one workaround. That last count is the number to watch: past about two workarounds you are on the road to the failure mode where half the codebase exists to fight the 20% that never fitted.

Only then does the ledger get written, and only then does the tempting middle option get considered and rejected: a "thin build" implementing just the three signature types actually needed. It looks like the 80/20 move and it is not. Signature validity is a legal question with jurisdictional edge cases that nobody on a four-person team can evaluate, and the €36,000 build price does not include the liability transfer — which is most of what the vendor is actually selling. Recognising what is really being purchased is the skill; the arithmetic is bookkeeping.

The sequel is the part worth remembering. Three years later the vendor raised prices 22% at renewal. Because the port existed, the team ran a three-week spike against a competitor, priced the switch at the €5,000 they had estimated, and used a credible alternative to negotiate the increase down. They never migrated. The port's return was not the migration it enabled — it was the negotiating position it created, and that return does not appear on any line of the ledger.

When this is the wrong move

Don't run the full ledger on a cheaply reversible decision. If the component is a library behind a port you could swap in a week, spend an hour and take the boring option — the meeting costs more than either choice. Don't run it when the component is small enough that the evaluation dominates the work: in an enterprise with a procurement process, a forty-hour component can take six weeks to buy, and procurement time is a cost of buying that no ledger line captures. And don't run it at all before you have named the unit: "build or buy our platform" is not a decision, it is a dozen decisions wearing one coat.

Skill: which ledger wins?

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.

In the lab. The phase-3 checkpoint has you run the build-vs-buy ledger for the carrier-label integration on the returns-resolution service — both columns, the exit cost, and the workaround count against the workflow steps — and then write the one sentence in which the differentiator test lands.

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.
• "In Defense of Not-Invented-Here Syndrome", Joel Spolsky — the primary statement of the differentiator rule: build your core competency, buy everything else.
• 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.