Building
Peeling Back the Onion
Building anything real is like peeling an onion. You don't design the layers. You discover them. And you never know whether the next one will be beautiful or deeply weird.
There's a moment early in any project where you think you understand the whole thing. You had the idea in the shower, or on a walk, or in the middle of a conversation that wasn't even about this. The shape of it felt complete. You could see the architecture. You were ready to build.
That feeling is a trap.
Not because the idea is bad—it might be great. But because understanding the surface of something is not the same as understanding its interior. The real structure of what you're building only reveals itself as you peel it back, layer by layer, with your hands.
Garry Tan put it well recently: “People get high on abstraction too early. They want the system before they've earned the insight.” The good abstractions, he argues, are never designed. They're discovered. You do the stupid manual thing enough times and the real bottleneck just emerges.
This is the onion. Each layer you peel back shows you something you couldn't have predicted from the outside. Sometimes it's elegant—a hidden symmetry, a simplification you didn't expect. Sometimes it's bizarre—an edge case that makes no sense until you realize it's the most common case. Sometimes it makes you cry.
The temptation, especially now, is to skip layers. AI makes it trivially easy to generate the abstraction before you've touched the raw material. You can scaffold an entire system in an afternoon. It feels like progress. It feels like power. But you've just built a beautiful wrapper around your own ignorance. You've scaled your misunderstanding.
Paul Graham's famous advice to “do things that don't scale” was never about suffering for its own sake. It was about contact. When you're the one manually doing the loop—answering support emails, deploying by hand, onboarding users one at a time—you see things that no amount of upfront design would reveal. The weird user behavior. The failure modes nobody planned for. The hidden dependencies that only surface at 2am when something breaks in a way you didn't know was possible.
Each of those discoveries is a layer. And each layer changes your understanding of every layer that came before it.
This is what makes building feel like art and science at the same time. You start with a hypothesis, but reality is the editor. The shape of the thing evolves under your hands. Your job isn't to protect your original vision—it's to stay close enough to the material that you can feel it changing.
The best builders I know share this quality: they're comfortable not knowing what the next layer looks like. They don't mistake the map for the territory. They peel, observe, adjust. They let the work teach them what it wants to be.
Formalize what you've learned. Build the recursive version. But keep checking that your abstraction is still attached to real humans and their needs. Because reality drifts. Your users drift. The ground truth shifts beneath you, and the only way to notice is to keep your hands on the onion.
The abstraction is a tool, not a destination. The moment you forget that—the moment you stop peeling—you're cooked.