2 posts tagged with "building"

In Rick Rubin's The Creative Act, there's an idea that caught my attention and stuck with me.

When musicians record a demo, they often fall in love with it. The specific sounds, the particular arrangement, all the little details that made it feel alive in that moment. But those details can become a cage. You can't expand a completed version when there's no room to grow.

So what do some of the best do? They write the demo out as sheet music. Strip it to the skeleton: just the melody, the chords, the structure. Destroy everything that isn't essential. Then hand it to the band and rebuild from the bones.

The result isn't a polished version of the original. It's something new, something with room to breathe.

Distill Before You Expand​

This connects to something Charlie Munger talks about: inversion. Instead of asking "how do I make this better?" you ask "what would make this worse?" and then avoid those things. Don't try to be brilliant. Just don't be stupid.

The instinct for most builders is to add. When something isn't working, the question is usually "what can I add to fix it?" But sometimes the better question is "what can I remove?"

Not every problem needs a new feature. Sometimes the answer is fewer moving parts, not more.

Destruction Is a Variant of Done​

There's a short document called the Cult of Done Manifesto, written by Bre Pettis and Kio Stark in 2009. It has thirteen principles about finishing things, and principle eleven says simply: "Destruction is a variant of done."

That reframes everything. Throwing something away isn't failure. It's completion. Tearing something down to its core and starting fresh isn't going backward, it's a form of finishing. You're done with the version that no longer serves you.

The manifesto also says "done is the engine of more." Completion isn't the end, it's what creates space for the next thing. And sometimes the fastest way to complete something is to destroy the parts that are weighing it down.

The Eye for Importance​

The real skill isn't building. Anyone can add. The skill is knowing what's load-bearing and what's just there.

Systems want to expand. Features accumulate. Complexity creeps in because each addition made sense at the time. But eventually you're maintaining things that don't matter anymore, and the weight of all that maintenance slows everything down.

This is especially relevant now that AI can generate and expand almost anything on demand. The bottleneck isn't creation anymore. It's curation. Knowing what to keep and what to cut. Having an eye for the essential.

Expansion is easy. Distillation is hard.

Rebuild From the Bones​

The Rubin insight isn't about destruction for its own sake. It's about creating room. You strip something to its skeleton not to abandon it, but to rebuild it better. The melody is still there. The core is still there. But now there's space to grow in directions the original version couldn't accommodate.

If you're a builder, someone who loves adding layers and refining systems, this might feel counterintuitive. The instinct to add is strong because it feels like progress. But sometimes the most productive thing you can do is subtract. Strip something back to its bones, see what's actually essential, and only then decide what deserves to be rebuilt.

What have you built that might need breaking down?

I've had this vision in my head for years. The perfect note-taking app. Voice capture that transcribes instantly. AI that condenses my rambling into something useful. A fluid interface where I could zoom in and out of my thoughts like a map of my own mind.

I'd cobbled together something close using Obsidian and various plugins, but it never felt quite right. Then I discovered Claude Code, an AI that could actually write production software, and something clicked. I'd gotten pretty skilled at prompting. Maybe I could finally build the real thing, the app that matched my vision exactly.

So I started building.

Two Weeks of Creation​

It came together faster than I expected. Voice notes that transcribed and condensed themselves. A zoom slider that moved smoothly between single keywords and full paragraphs. Offline support so it would work at the gym where the WiFi blocks half the internet. A progressive web app that ran on my phone without going through any app store.

Every day I'd work on it while Flynn napped, adding features, fixing bugs, watching my vision materialize on screen. I learned how to host a website, how to manage domains, how to forward emails, how to optimize for mobile. I learned actual web development, not just prompting but understanding what the code was doing and why.

By the end of two weeks, I had something genuinely useful. Something that worked exactly the way I'd imagined. My note app, running on my domain, built to my specifications.

And then Inwu asked me a question.

The Question​

"What's the goal here?"

She wasn't being dismissive. She's never dismissive about my projects. But she's precise, and she saw something I was too deep in the building to see.

If I wanted this to be more than a personal tool, it would become a business. Taxes, support, hiring, marketing. A note-taking app, one of hundreds already fighting for attention in a market where AI plus notes is literally everyone's first idea. There are so many of them now. They're all trying to do this.

Meanwhile, I'd spent the past year building something else: a trading system. An AI council that debates market positions. Algorithms that manage my capital while I sleep. That system has already doubled my money. It runs almost autonomously. There are no users, no support tickets, no company to build. Just me and my capital and an edge that keeps compounding.

Which one should I be spending my time on?

The Opportunity Cost of Everything​

My financial skills are rare. Trading edges are scarce, and I actually have one. Note-taking apps are crowded, and even the best ones struggle to make money. The answer was obvious once I stopped to look at it.

And there's something else. Flynn is nine months old. I'm on parental leave until next fall. This window, where I can watch him discover how blocks stack and cheer when he pulls himself up on the furniture, doesn't reopen. He'll never be this age again, and I'll never get this time back.

Every hour I spend debugging a UI quirk is an hour I'm not present with him. Every feature I add is a feature I'm choosing over my son.

What Essentialism Means Now​

This forced me to rethink what essentialism actually means.

Essentialism used to be about effort scarcity. You only have so many hours, so much energy, so much willpower. The discipline was doing fewer things because you couldn't do everything. Pick the vital few. Say no to the rest.

But what happens when doing becomes cheap? I can spin up a new feature in an afternoon. Claude writes most of the code. I provide direction, test it, iterate. The effort barrier that used to protect me from my own ideas has collapsed.

The scarcity didn't disappear. It shifted. Now the scarce resource isn't effort. It's attention. It's meaning. It's the finite capacity to care about things deeply enough to maintain them, to use them, to let them serve your actual life instead of becoming another thing you built and forgot.

The old discipline was "can I make this?" The new discipline is "should I?"

That's harder. Saying no to impossible things is easy. Your limitations do the work for you. Saying no to possible things, things you could ship this afternoon, things that would be genuinely useful, that takes real clarity about what matters.

What I Actually Learned​

Two weeks of building wasn't wasted. I learned Claude Code and how to work with an AI on real software. I learned web hosting, domain management, mobile optimization, progressive web apps. I learned how to turn a vision into working software.

But the most valuable thing I learned was this: the skill isn't in the building anymore. AI has made creation trivially easy. You can imagine something and watch it materialize in days instead of months. The hard part now is knowing what not to build.

Finished, Not Abandoned​

Liquid Notes works. It captures my voice notes, transcribes them, condenses them, syncs across devices. It does what I need it to do.

I'm not abandoning it. I'm declaring it finished. The difference matters to me. Abandoned means failure. Finished means the work is complete, not because there's nothing left to add, but because I've chosen to stop adding. The app works. It serves its purpose. And my time is better spent elsewhere.

My energy goes to the trading system now, the one that actually compounds. It goes to Flynn, who won't be nine months old again. It goes to being present with Inwu instead of debugging edge cases at midnight.

When you can build anything, the hardest question isn't "how?" It's "should I?"

And sometimes the answer is: I already have enough. Time to stop.