---
id: 31
title: "Own your components — when you deeply understand the domain"
status: current
date: 2026-06-12
authors:
  - "Theo Zourzouvillys"
tags: [architecture, process, llm, design]
summary: "Owning your own components rather than generic off-the-shelf services is often the better path as you grow: own what's core, lean on small vetted libraries for the hard parts. LLMs make it attainable at smaller scale — but only when you truly understand the domain, or it hurts."
supersedes: null
superseded_by: null
aliases: []
---

## 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](/zfn/28-llm-brute-force-prs-understanding/)).

## 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](/zfn/30-use-standards-dont-reinvent/).** 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](/zfn/30-use-standards-dont-reinvent/)). 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/1-engineering-decision-records/),
  [ZFN-14](/zfn/14-schema-first-apis-generate-clients/)). 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](/zfn/28-llm-brute-force-prs-understanding/)). 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](/zfn/23-iterate-and-rewrite-implementations/)).

**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](/zfn/30-use-standards-dont-reinvent/) — the complement: use the standard *protocol/format*;
  this note is about owning the *implementation* that speaks it.
- [ZFN-28](/zfn/28-llm-brute-force-prs-understanding/) — the failure mode this note guards against:
  building (or shipping) what you don't understand because the tool let you.
- [ZFN-23](/zfn/23-iterate-and-rewrite-implementations/) — owning a component behind a clean interface
  makes it cheap to evolve or replace.
- [ZFN-20](/zfn/20-deliberate-complexity-is-often-simpler/) — 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.