18  Principle Eight — Absorb, Don’t Rebuild

Every engineering team eventually faces the seductive question: this component exists and is free, but building our own would take only a month and would be exactly what we need. In clinical software, where the open ecosystem now covers enormous territory — table engines, analysis functions, listings, synthetic data, catalogs — the question arrives weekly.

The principle: default to absorbing; treat every rebuild as a decision that must justify itself in writing. Not because open source is sacred, but because the strategic question is never “can we build this?” It is “is this where our scarce differentiation comes from?”

18.1 The buy-build map for a trust product

Draw a line through the clinical reporting stack. Below the line: computation — table layout engines, standard analyses, figure kernels, ADaM derivation machinery, synthetic data generators. Above the line: evidence — replay, independent comparison, provenance graphs, validation packages, gates, the delivery of accountability itself.

Everything below the line is being commoditized by well-funded open source and will only get more commoditized. Everything above the line is structurally unattractive to the component ecosystem, because it is unglamorous, hard to demo at conferences, and only valuable as an integrated whole. That asymmetry is a gift. It says: spend your single-digit engineering capacity exclusively above the line, and buy — absorb — everything below it.

The failure mode has a signature. A team starts building its own table engine “just for the basics.” Eighteen months later the table engine has footnotes, pagination, three output formats, a shrine of edge cases, and the trust layer still does not exist — but a competitor that consumed the open engine and built the layer is now in procurement conversations. The team did not lose because it built badly. It lost because it built the wrong layer.

18.2 Absorption has its own disciplines

Absorbing is not the same as importing and praying. Open components enter a trust product through a regime, not a shopping cart:

• Pin everything. Versions are locked — by commit, by lockfile, by hash. A trust system that floats on “latest” has outsourced its behavior to strangers’ release managers.
• Qualify through your own gates. An absorbed engine earns its place the same way homegrown code does: through the comparison machinery, run against locked references, with results recorded. Absorption without qualification is just a different way to import risk.
• Wrap at the contract border. The engine sits behind your versioned contract, so that the day a better engine appears — or the current one dies — replacement is a swap behind a stable interface, not a rewrite.
• Record provenance. Where code came from, which version, what was verified: entries in the same graph as everything else.

18.3 When rebuilding is right

Sometimes the answer genuinely is “build” — when the capability is the differentiation (a comparator with cell-level, tri-state semantics has no open equivalent), when the absorbed component’s failure modes cannot be qualified into trust, or when a thin shim over a mismatched abstraction costs more than a focused rebuild. The principle does not forbid building. It forbids building reflexively — and it demands that each such decision be written down as an architecture record, so that eighteen months later the team can remember why the line was drawn there and move it deliberately rather than accidentally.

The test. List your system’s components. For each, ask: “Does our differentiation live here, or does it live in what we wrap around it?” If you find differentiation being spent below the line — in capabilities a free package already ships — you are subsidizing the commodity layer with your scarcest resource.