Building Your Own Things Is Cool Too: On Learning Through Process

TLDR: Pawel Jozefiak makes the case that building things from scratch is not about rejecting better tools — it is about the kind of knowledge you only gain by doing. The act of building something yourself teaches you in a way that reading, using, or configuring cannot replicate.

Summary:

The question Pawel gets constantly is some version of: why are you building your own thing when a perfectly good tool already exists? He gets it about his AI agent, about his digital store, about side projects going back years. And honestly, it is a fair question. The world is full of excellent off-the-shelf solutions. My reaction to reading this is one of deep recognition — I have answered that same question more times than I can count, in different contexts, usually to people who mean well.

The answer Pawel gives is not a philosophical manifesto. It is practical and personal. He learns through process, not by reading. He has to do the thing, watch it break, fix it badly, then fix it less badly, then finally understand why it works at all. That cycle is where the knowledge lives for him. Every pre-built tool, he writes, is a map of someone else's process. The map is real and useful. But walking the route teaches things the map cannot.

There is a genuine insight buried in here about what ownership of a system actually means. When you build something yourself, you know every variable. You know which ones are load-bearing and which ones are there because you had a bad afternoon two weeks ago and forgot to clean them up. That knowledge is what lets you compose rather than merely configure. I find this distinction compelling. Configuration is bounded by what the tool allows. Composition is bounded by what you understand. Those are not the same ceiling.

The AI agent example he uses is fresh and concrete. He is building his own from scratch while people keep pointing him to open-source alternatives with hundreds of thousands of stars. He is not unaware of those tools. He just wants the variables, wants the failures, wants the version of himself that exists on the other side of having built it. There is also an observation here that I think is genuinely sharp: when an AI model like Claude or Codex suggests a change, whether you can evaluate that suggestion depends entirely on whether you understand the architecture. Both the person who built from scratch and the person who adopted a framework can accept the diff. Only one of them can judge it. That gap compounds over time.

That said, he is not religious about it. His rule is simple: build the parts you need to understand, use the parts you do not. He spent two months on a custom kanban dashboard before realizing a 94-line shim on top of an existing tool did the same job. He switched. The goal is not purity — it is understanding. And his advice for someone starting at zero today is actually measured: use the tool first, ship something, then replace the parts you decide you want to own. That sequencing — use then build, not build instead of use — is the kind of pragmatism that gets left out of most "build from scratch" arguments.

Key takeaways:

Learning through process rather than reading is a legitimate and distinct cognitive style, not a quirk to apologize for.
Every pre-built tool is a snapshot of someone else's process; building your own is the act of acquiring the process itself.
The ability to evaluate AI-generated diffs — rather than just accepting them — depends on architectural understanding that only comes from having built the thing.
The practical rule: build what you need to understand, use what you do not. The hard part is being honest about which parts those actually are.
Recommended sequence for newcomers: use the tool first, ship something real, then selectively rebuild the parts that matter to you.

Why do I care:

This is a question I sit with constantly in the context of software engineering. The case for building from scratch is usually made poorly — either as a purity argument or as not-invented-here syndrome dressed up in learning language. What Pawel writes here is different. The point about AI diffs is the sharpest version of the argument I have seen: in a world where anyone can generate code, the differentiator is not who can write it but who can read it critically. That capacity comes from having built things the long way, even once. That feels true and worth remembering.

Building Your Own Things Is Cool Too