When you scope a new tool, the full stack it appears to require can look enormous. There’s the input handling, the parsing, the storage, the search, the interface, and somewhere in there, the actual thing the tool is for. The novice instinct is to treat the whole stack as the project and start building from the bottom. The experienced instinct is to ask, layer by layer, which of these is genuinely yours to build and which already exists as solved, reusable infrastructure you’d be foolish to reconstruct. Usually, the part that’s actually yours is a thin slice near the top, and most of what’s underneath is a commodity.

The distinction is between the plumbing and the domain layer. The plumbing is everything that is the same across a thousand tools: reading a file, chunking it, caching results, handling the formats, moving data around. It is hard to build well, which is exactly why mature, well-tested versions of it already exist and are usually free. The domain layer is the part that encodes the specific understanding your tool exists to provide — the rules, the schema, the judgment particular to your problem that no general-purpose component knows. That layer is small, but it is the entire reason the tool has a reason to exist, and it is the only part no one has built for you.

Conflating the two is the most common way a small project becomes a large one. A founder who decides to build the plumbing because it feels foundational spends most of their time reconstructing a commodity, and arrives at the domain layer — the only part that matters — exhausted and behind. The plumbing they built is, at best, as good as the off-the-shelf version they could have adopted in an afternoon, and at worst, a buggy subset of it. The effort was real and the result was a wash, because the work went into the layer where there was no advantage to be had.

Recognizing the thin layer requires honestly auditing each part of the stack with one question: does anyone else need exactly this? If the answer is yes — everyone parsing this format needs this, everyone caching needs that — it’s plumbing, and someone has already built it. If the answer is no, this encodes something specific to my problem that a general tool wouldn’t know, then it’s yours, and it’s where your effort belongs. The audit is uncomfortable because it shrinks the part you get to build, but shrinking that part is the point. A smaller surface of genuinely-yours work is a faster, more focused, more defensible project.

The reuse this enables is not laziness; it is leverage. Adopting solved infrastructure for the commodity layers means the entire budget of attention, time, and care goes into the layer that differentiates the tool. The domain logic gets the polish that would otherwise have been spent reinventing file handling. And because the plumbing underneath is mature and widely used, it is more reliable than anything a solo effort would produce on a first pass. You inherit other people’s years of edge-case fixes for free, and spend your own time only where time spent actually compounds into advantage.

The discipline, then, is to resist the appeal of building from the bottom. The bottom is solved; building it feels productive and produces nothing distinctive. Start instead from the question of what your tool uniquely knows, build exactly that, and let it rest on the broadest possible foundation of things other people have already made reliable. The tool that ships is the one whose builder spent their effort on the thin layer that was theirs — and refused, everywhere else, to rebuild what was already done.