Ownership Outlives the Build

A load-bearing layer keeps charging after it is written: patches, incidents, security fixes and the hours of whoever owns it, for as long as anything stands on it. A maintained community spreads that charge across everyone who uses the layer; a hand-rolled, forked or abandoned one puts it on a single owner, and the owner's attention is the scarcest thing this canon manages. So the cost column of any infrastructure decision is the lifetime, not the first version; it names who pays, and it is written where the decision is recorded. The layers in scope are the ones other work stands on: a UI framework, a database, auth, transport, build tooling, crypto, queues, rendering, localisation. A thin wrapper over a maintained library is borrowing; only the wrapper is priced. A borrowed layer can be abandoned upstream too; that risk stays in the lifetime column rather than being pretended away. Provisional approval covers reversible work and never a load-bearing layer. The practice this produces is canon/methods/library-not-hand-rolled.

A layer is load-bearing when other work stands on it and cannot easily move off it: the framework a user interface is written in, a database or storage engine, authentication, a transport or protocol implementation, build tooling, cryptography, scheduling and queues, document rendering, localisation. These layers share one economic shape. The first version is cheap, often a pleasant afternoon. Everything after the first version is paid for as long as the layer runs, and it is paid by whoever owns the layer, alone.

This canon already holds that the real cost of work is what it takes to undo, not what it takes to think (irreversibility-is-the-real-cost), and that when creation becomes nearly free the human costs of attention and judgment do not fall with it (capability-is-not-permission). This principle is the meeting of those two: a load-bearing layer is expensive to undo precisely because other work stands on it, and the cost it keeps charging is attention.

1. Price the lifetime, not the first version. When a plan, evaluation or review weighs a load-bearing layer, the cost column is patches, incidents, security fixes and seat-hours over the layer's expected life. First-version effort is a line item in that column, never the total.
2. Ownership is singular. A layer no community maintains has exactly one owner: whoever built, forked or adopted it. That owner pays every future cost, whether or not they still remember choosing to.
3. A community amortises. A maintained implementation spreads the same lifetime cost across every user, maintainer and bug reporter it has. The difference between one owner and thousands is the whole argument for borrowing.
4. Abandonment transfers the cost. Adopting an unmaintained or single-maintainer source transfers its lifetime cost to the adopter at the moment of adoption. A fork into a private line does the same.
5. The accounting is written down. A decision that accepts the lifetime cost of a hand-rolled or unmaintained layer records that cost, in words, where the decision is recorded. An unwritten cost is paid anyway; it is only paid by surprise.

• Use when: a plan, ticket, evaluation or review must weigh the cost of a layer other work will stand on: a UI framework, database, auth, transport, build tooling, crypto, queue, rendering, localisation, or anything a project cannot easily move off.
• Skip when: the choice is application logic, domain code, glue, a script, a prototype, or anything written to be regenerated or thrown away; or the question is which maintained option to borrow rather than whether to borrow at all.
• Stop when: the decision record states the layer's lifetime cost in words and who will pay it, and the choice has been made against that cost rather than against first-version effort.
• Keep going when: a cost estimate counts only the build; the owner of a layer is unnamed; a fork or adoption of an unmaintained source has no written cost beside it.
• Where: planning records, six-row evaluations, tickets that add or change a load-bearing layer, and the review receipts beside them.
• Who: anyone proposing, evaluating or reviewing a load-bearing layer: agents and operators alike.
• Why: first-version effort is the one cost that is visible when the choice is made and the one that matters least afterwards (§ Grounds).
• What: a principle: the cost of load-bearing infrastructure is its lifetime of care, so it is priced over that lifetime, and the owner of that lifetime is named.
• How: apply the five rules under § Principle; record the accounting as § What This Means in Practice describes; recognise drift with § Failure Modes.

The two cases (protocol servers hand-rolled until a convention bound an SDK, 2026-09-02; a production UI run for months without a framework, 2026-10-16) are recorded once, in canon/methods/library-not-hand-rolled § Grounds. What this page takes from them is the cost shape: each hand-rolled copy was quick to write and belonged to one person afterwards, and the UI components were small while the layer they established was not.

The operator, 2026-10-16, cleaned for grammar with his review (the raw lines stay in the private transcript): "I'm frustrated that a production UI would use vanilla JS without the benefit of a community-maintained framework." On why: "You can build it in beautiful reusable abstractions. But state and memory management and a billion other things are addressed for us in UI frameworks." On himself: "If I want to build my own database from scratch, tell me the risks and make me think about it."

Confidence: a working rule with two cases and one operator. Proposed, not stable; stability moves only after a second independent adoption, recorded as a dated amendment.

The cost column of any infrastructure decision names a lifetime: years, not hours. It counts patches, incidents, security fixes and the hours of the one person who will field them. It names that person. When the layer is borrowed from a maintained community, the column says so and the owner is the community. When the layer is built, forked or adopted from an unmaintained source, the column says who owns it now and what that is expected to cost, and the proposer signs it. The practice that turns this accounting into a default and a review step is canon/methods/library-not-hand-rolled.

Building stays allowed; it is priced over its lifetime before it is chosen. The maintained choice is usually, not always, cheaper over that lifetime (§ Principle 3), and the comparison is what the principle requires. Out of scope: application logic, domain code, glue, scripts, prototypes and anything written to be regenerated, which "regenerate, don't steer" already covers. A thin project-owned interface over a maintained library is in scope only for the small layer the project owns, which is priced like any other; the moving ground beneath it, the parsing, the transport, the crypto, stays the community's to maintain, and that is why wrapping is borrowing. Who may make the choice, and the rule that silence is not agreement, belong to canon/principles/silence-is-not-consent; this page decides only how the choice is costed.

Where this diverges from its parents: irreversibility-is-the-real-cost prices the undo; this principle prices the ongoing care that makes a layer expensive to undo in the first place. capability-is-not-permission says cheap creation needs imposed constraint; this principle names one constraint, lifetime accounting, for one class of creation.

Prior art and the strongest opposing view. The economic idea has names elsewhere: total cost of ownership in procurement, "not invented here" as the bias this principle corrects, and the dependency-risk literature's warning that a borrowed layer can be abandoned upstream too. That last point is the strongest case against: a maintained library can lose its maintainers, and then the borrower owns it anyway. The answer is that the borrower owns it later, with a community's history, tests and forks to inherit, rather than alone from day one; the principle still prices that risk into the lifetime column rather than pretending borrowing is free. Counter-example considered and rejected: a tiny, stable layer with no security surface and no expected change, where the first version really is most of the lifetime. The scope line already excludes such layers; where one is genuinely load-bearing, the accounting still runs and comes out short, which is the correct result.

Falsifier. Retract or narrow this principle if, across the projects it governs, hand-rolled or unmaintained load-bearing layers prove cheaper to own over their lifetime than the maintained alternatives they replaced, measured in patches, incidents and seat-hours rather than first-version effort. Record the result as a dated amendment with the evidence.

• Library, Not Hand-Rolled (canon/methods/library-not-hand-rolled.md) — the method this principle produces: borrow by default, red-flag the exception, answer in writing before building.
• Silence Is Not Consent (canon/principles/silence-is-not-consent.md) — the sibling principle: who must have rowed before a decision counts as made.
• Irreversibility Is the Real Cost (canon/principles/irreversibility-is-the-real-cost.md) — the parent: cost is what it takes to undo; this principle prices the care that makes undoing expensive.
• Capability Is Not Permission (canon/principles/capability-is-not-permission.md) — the parent: cheap creation does not make attention cheap; this principle names lifetime accounting as the imposed constraint for load-bearing layers.
• Borrow, Bend, Break, Beget, Bide, Build (canon/methods/borrow-bend-break-beget-build.md) — the sequence; this principle is why Borrow comes first for load-bearing layers.
• Borrow Evaluation Before Implementation (canon/constraints/borrow-evaluation-before-implementation.md) — the planning-mode binding whose cost rows this principle governs.
• Progress Over Perfection (canon/principles/progress-over-perfection.md) — provisional approval covers reversible work; a load-bearing layer is not that.