I Destroy Almost Everything I Build. Lego Taught Me How.

From a Lego castle on the living room carpet to a kanban board I shipped on three platforms and killed in six months.

The castle was finished. It matched the picture on the box, every flag in the right hole, and it had taken me most of a Saturday. Then I took it apart.

I was four, maybe five. I honestly can’t tell you which one. But I remember the feeling, and it had nothing to do with the castle. It was that I finally had the pieces.

That is the first thing I remember building, and it turned out to be the whole pattern.

Quick note before this goes anywhere. This post is more personal than what I usually send. Less measurement, more of what I actually think. I’ve also gone from three or four posts a week down to about one, deliberately, because there is a lot going on outside the newsletter and I’d rather the one post be something I actually sat with. If you’re here for the numbers, they’ll be back next week.

The instructions were never the point

I always started with the set. Spaceship, castle, whatever was in the box. I’d follow the booklet page by page and get exactly the thing the designer intended.

Then, usually within a day, it came apart.

The castle was fine. It had just stopped being interesting the second it was done. The set was the tutorial: following the instructions taught me which pieces clicked into which, where the hinges lived, what could carry weight and what would snap under it. Once that was in my hands, the castle was only a castle. The pieces were the good part.

By ten or eleven I had one huge box of mixed bricks and no sets at all. Houses, planes, helicopters. I was pulled toward anything that moved: folding wings, landing gear that retracted, a car that could fold itself into a robot. Static things bored me fast. If it couldn’t change shape, I had already seen everything it had.

I kept doing this well into my teens, which at the time felt like something to keep quiet about. It doesn’t now.

Building good, destroying bad

Somewhere along the way I picked up a rule nobody actually taught me. Building is good, destroying is bad.

That sounds harmless. It isn’t. It made me keep things.

Everything I finished, I got attached to. I had poured hours and thought into it, so throwing it out felt like admitting the hours were wasted. So I kept it. Then the next one, then the one after that. For years I hauled around a pile of finished things I no longer used and couldn’t bring myself to delete, and I thought that was what caring about your work looked like. Sixteen products in two months and zero free time is what that instinct looks like once you point an AI agent at it.

It took me a long time to see it the other way around. Destroying is the second half of building. The creative act includes the delete key.

Sometimes what you built is bad and it has to go. Sometimes what you built is perfectly fine and it still has to go, because the space it occupies is worth more than it is. The balance between those two is where the freedom actually lives. Without it you are just accumulating.

The same thing shows up in maintenance. When I finally sat down and read my agent’s own instruction files line by line, I found 85 things worth deleting. Almost nothing was broken. The system simply ran better with less in it.

What I have actually killed

Some of you watched this happen in real time.

In December 2024 I built a public chat app. Rails 8, WebSockets, no accounts, no logins, drama-free by design, a deliberate throwback to the chat rooms of the late nineties. It was harder than I expected. Even with AI helping I had to actually understand sessions, channels, broadcasting, what real time means when two browsers disagree about the truth. The learning was the whole payoff.

It ran publicly for a couple of months. Then I switched it off. Not because it broke. Because I had gotten what I came for and was never going to develop it further. Keeping it alive would have been sentiment with a hosting bill attached.

Then there is the one I am least proud of and learned the most from.

Across January and February 2026 I built my own kanban system for the agent. FastAPI backend, SQLite, a web app, a native macOS app with a menu bar item, a native iOS app with widgets and push notifications, and a 3,700 line Python client gluing it to everything else. Fifty-four commits. Two months of evenings.

In April I replaced the whole stack with an off-the-shelf board and a 94 line shim. In May I retired the replacement. In July I retired the one after that. Today the same job runs on TickTick, an app I did not write, plus a small local registry file.

Same function, three retirements, six months. Every one of them was the right call at the time.

The uncomfortable version of that story is that I spent two months of my life building a to-do list. The useful version is that I now know precisely what I want out of one, which is exactly why a 94 line shim is enough and why I stopped caring which board sits underneath it.

The process is the part you keep

Building something for the first time is expensive in the best way. You hit walls you didn’t know were there. You learn concepts you cannot learn by reading about them, because reading doesn’t force you to handle the edge cases at 11pm when it half works.

That knowledge never lived in the repo. It lives in you, and it stays after the repo is gone.

Which is also why deleting things stopped costing me anything emotionally. The value already transferred. What’s left on disk is a receipt.

None of this is specific to code. Same with Lego, same with a piece of furniture, same with a plan you spent a week on. The first pass is where the learning is. The second time through you’re just executing.

About the frameworks

I get a version of this question in the comments and my DMs constantly. Why build your own agent when OpenClaw exists, or Hermes, or any of the other good open source ones? Why not at least borrow the architecture from people who have already solved it?

I’ve answered it twice, once about preferring my own spells and once about building your own things. Here’s the part I left out, and it took me until this post to see it clearly.

I do read them. I follow what OpenClaw ships, I’ve been through what Nous Research put out with Hermes, I look at how each one handles memory, scheduling, tool access, what they let the agent touch and what they refuse. I am not building in the dark.

Although I go after the schematic, not the thing.

It is the instruction booklet again. I want to see how the designer solved it, understand why those pieces fit together in that order, then put the booklet down and build my own version out of the mixed box. The mistakes I make on the way are the point. A mistake you had to climb out of stays learned in a way that a working config file never does.

Is it slower? Yes, obviously. If I pulled in a whole framework I would be further ahead this month. I would also understand my own system less, and that is the one trade I’m not willing to make. Like, the whole reason I can debug this thing at 2am is that I made every bad decision in it personally. And the more architectures I’ve actually taken apart, the better my own designs get. That part compounds quietly.

Filip does it too

My son is five. We build sets together and we follow the booklet, because that part is genuinely fun and he likes getting it right.

Then the set comes apart on the living room carpet and we build our own cars, our own planes, our own spaceships out of whatever is in reach. He’ll hunt for one specific piece for ten minutes and refuse every substitute I offer him. I know that hunt.

I never sat him down and explained any of this. He arrived there on his own, which makes me suspect it was never really a lesson in the first place. It’s just what building looks like before somebody tells you that finished things are supposed to stay finished.

Still taking things apart

I destroy things faster than I make them, and I’ve stopped trying to fix that about myself. Starting things is cool, I wrote almost two years ago, and I still mean every word of it. Ending them is the half I had to learn late.

Somewhere at my parents’ place there is still that box. Nothing in it is a set anymore.

If you’d rather hear about the projects that got deleted than the ones that shipped, subscribe to Digital Thoughts. Both show up here, and the dead ones usually taught me more.