Own your components — when you deeply understand the domain

TL;DR

Implementing your own components instead of pulling a generic thing off the shelf isn’t just OK — as you grow it’s often the better path. Owning a component means it fits your needs exactly, has only the surface you actually use, carries no external dependency or vendor, and is something you fully understand and can evolve. LLMs make this dramatically more attainable: building exactly what you need, leaning on small, constrained, vetted libraries for the genuinely hard parts, is cheaper than it has ever been — so the scale at which “own it” beats “buy it” has dropped a lot. Favour your real needs, document what the component does, and don’t reach for an external service that’s generic overkill when you could own the small thing internally.

One hard, non-negotiable condition, stated forcefully: only do this when you understand the domain, the protocols, and the architecture really well. If you don’t understand the scope, do not build it — you’ll hurt yourself badly. This is the exact opposite of brute-forcing something you don’t grasp (ZFN-28Open problem · currentZFN-28 — Capability without understanding: brute-force LLM PRsAn open problem: people brute-force PRs with LLMs in domains they don't understand, taking on more than their knowledge supports — and the struggle that used to teach them is smoothed away. How do we stop un-understood code without killing learning or banning a good tool?Open ZFN-28 →).

Context

The reflex to reach for an off-the-shelf library, framework, or SaaS for every need is strong, and for commodity things you don’t understand and don’t want to, it’s right. But two things change the calculus as an organization grows:

• Generic is overkill, and overkill has a cost. A general-purpose service or framework is built to satisfy everyone, so it carries enormous surface you don’t use, assumptions that fight your model, a dependency or vendor you don’t control, data leaving your boundary, per-unit cost at scale, latency, and an SLA that’s now yours to worry about. You adopt the whole iceberg to use the tip.
• Owning the small thing you actually need is cleaner — if you can afford to build it. It has only the surface you use, fits your architecture, removes an external dependency, and is something your team understands. This has always been true; it’s why growing companies bring more and more in-house as they can afford the engineering.

What’s new is the price. LLMs drop both the cost of building the component and the cost of acquiring the understanding to build it well — so the org size at which in-house beats off-the-shelf has fallen sharply. Things that only made sense to own at hundreds of engineers can make sense to own at a handful now.

This is not in tension with ZFN-30Field Note · currentZFN-30 — Use the standard; don't reinvent the protocolWhen a standard exists for a common or complex problem, use it — don't reinvent the protocol. Standards encode huge adversarial expertise, especially in auth and crypto; a partial implementation beats rolling your own. You're not that special, and your problem isn't either.Open ZFN-30 →. That note says don’t reinvent the protocol, format, or cryptography — use OpenID Connect, JWT, the standard. This note says own the implementation/component — build your token service around a small JOSE library rather than buying a generic auth platform that’s overkill. Use the standard; own the code that speaks it.

Recommendation

Own what’s core and where you have deep understanding; buy the commodity and the things you don’t.

• Build to your real needs, not the generic case. Implement the small component that does exactly what your system requires, instead of adopting a heavyweight generic dependency or external service and using 10% of it. Less surface, fewer assumptions, no iceberg.
• Lean on small, constrained, vetted libraries for the hard parts. Don’t reimplement the genuinely difficult primitives (crypto, parsing, compression) — use a focused, auditable library and the standard (ZFN-30Field Note · currentZFN-30 — Use the standard; don't reinvent the protocolWhen a standard exists for a common or complex problem, use it — don't reinvent the protocol. Standards encode huge adversarial expertise, especially in auth and crypto; a partial implementation beats rolling your own. You're not that special, and your problem isn't either.Open ZFN-30 →). Own the orchestration and the fit; borrow the hardened core.
• Prefer owning over an external service when the service is generic overkill. A dependency that takes your data outside, locks you in, costs per unit at scale, or adds a network hop and an SLA — for functionality you understand and could own — is often the worse trade as you grow.
• Document it as a first-class system. Because you own it, write down what the component does, its contract, its boundaries, and its trade-offs (ZFN-1Field Note · currentZFN-1 — Keep engineering decision recordsRecord significant engineering decisions as short, versioned markdown files — context, decision, consequences. Write one for cross-team contracts, directional principles, hard-to-reverse choices, and conventions others must follow. Cite them instead of re-arguing.Open ZFN-1 →, ZFN-14Field Note · currentZFN-14 — Define every API with a schema, and generate the clientsDefine every API with a machine-readable schema (OpenAPI, Protobuf, GraphQL) as the source of truth, and generate clients and server stubs from it — never hand-roll request-building and JSON parsing. Hand-written clients drift and break silently; check schema compatibility in CI.Open ZFN-14 →). Ownership without documentation is just future pain.

The condition — and it is absolute

Only build it if you understand the domain, the protocols, and the architecture deeply. This is the condition the whole note rests on, and I mean it forcefully:

• Owning a component you understand is a force-multiplier. Owning one you don’t is a slow-motion disaster — you’ll get the edge cases, the failure modes, and (especially) the security wrong, and you won’t even know which questions you failed to ask.
• LLMs make the code appear effortlessly, which makes this trap far easier to fall into: you can now produce a plausible implementation of something you don’t understand, and ship a liability you can’t reason about (ZFN-28Open problem · currentZFN-28 — Capability without understanding: brute-force LLM PRsAn open problem: people brute-force PRs with LLMs in domains they don't understand, taking on more than their knowledge supports — and the struggle that used to teach them is smoothed away. How do we stop un-understood code without killing learning or banning a good tool?Open ZFN-28 →). Capability is not comprehension.
• So the gate is understanding, not ability-to-produce. If you don’t genuinely grasp the scope — the domain, the protocol, the failure modes, the security model — don’t build it. Use the off-the-shelf option, and learn the domain first. There is no shame in buying what you don’t yet understand; there is real harm in owning it anyway.

Consequences

Easier:

• The component fits your needs exactly, with no generic bloat, no fought-against assumptions, and a surface you fully understand and can evolve, debug, and optimize.
• You shed an external dependency / vendor / service — its cost, lock-in, data exposure, latency, and SLA risk — for functionality core to you.
• LLMs make both the build and the understanding cheaper, so this is viable far earlier than before.
• Behind a clean interface, an owned component is also easy to replace or rewrite later (ZFN-23Field Note · currentZFN-23 — Rewriting an implementation is fine — refactoring isn't always the answerRefactoring isn't always right. When the structure is wrong at the root, it's fine — often better — to rewrite an implementation from scratch. Clean interfaces and data models make the implementation disposable: stable contract, swappable internals. LLMs make it cheaper still.Open ZFN-23 →).

Harder:

• You now own it — forever: maintenance, security, on-call, and the documentation to keep it understandable. “Buy” externalises that; “build” keeps it.
• The understanding bar is real and unforgiving, and LLMs make it dangerously easy to skip — producing code you can’t stand behind. Misjudging your own understanding is the central risk.
• Build-vs-buy is a genuine judgement call each time; “own everything” is as wrong as “buy everything,” and the line moves with your scale and your team’s depth.
• Some things really are commodity, or genuinely beyond your understanding to own safely — and for those, off-the-shelf is simply correct.

References

• ZFN-30Field Note · currentZFN-30 — Use the standard; don't reinvent the protocolWhen a standard exists for a common or complex problem, use it — don't reinvent the protocol. Standards encode huge adversarial expertise, especially in auth and crypto; a partial implementation beats rolling your own. You're not that special, and your problem isn't either.Open ZFN-30 → — the complement: use the standard protocol/format; this note is about owning the implementation that speaks it.
• ZFN-28Open problem · currentZFN-28 — Capability without understanding: brute-force LLM PRsAn open problem: people brute-force PRs with LLMs in domains they don't understand, taking on more than their knowledge supports — and the struggle that used to teach them is smoothed away. How do we stop un-understood code without killing learning or banning a good tool?Open ZFN-28 → — the failure mode this note guards against: building (or shipping) what you don’t understand because the tool let you.
• ZFN-23Field Note · currentZFN-23 — Rewriting an implementation is fine — refactoring isn't always the answerRefactoring isn't always right. When the structure is wrong at the root, it's fine — often better — to rewrite an implementation from scratch. Clean interfaces and data models make the implementation disposable: stable contract, swappable internals. LLMs make it cheaper still.Open ZFN-23 → — owning a component behind a clean interface makes it cheap to evolve or replace.
• ZFN-20Field Note · currentZFN-20 — The simplest-looking system is often the most complex to live withThe system that's simplest to stand up often isn't simplest to live with — it skips the correctness edge cases, so bugs and inconsistency surface fast. A more deliberate design has more parts but fewer surprises, and is often the simpler one over time.Open ZFN-20 → — own deliberately; don’t take on a component whose essential complexity you can’t carry.

Changelog

• 2026-06-12: First published as a Field Note.