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-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-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-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-1, 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-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-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-30 — the complement: use the standard protocol/format; this note is about owning the implementation that speaks it.
• ZFN-28 — the failure mode this note guards against: building (or shipping) what you don’t understand because the tool let you.
• ZFN-23 — owning a component behind a clean interface makes it cheap to evolve or replace.
• 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.