Why I Build Things

One line: I build things because making tiny, imperfect stuff is the fastest path from "idea" to "I know something now."
Subtitle: less theory, more chaos. More shipping, fewer meetings. ✨

⚡ Pro tip: if you can finish it in a weekend, you're learning faster than if you read three docs and never touch the keyboard.

The Hook: Why side projects beat passive learning

At work I solve other people's constraints. Side projects are where I break rules, try new tools, and learn how things actually fail in the wild. It's like a low-stakes lab for curiosity.

• Work gives you requirements, budgets, and legacy code.
• Side projects give you permission to be weird, to refactor with abandon, and to throw away things that don't work.

Yes, sometimes they fail. Good. Failure is feedback served quickly — the most honest kind.

NOTE: Shipping is a pressure test. A todo app that sits on your laptop is a draft. A todo app that other humans actually click is a mirror.

How I treat side projects (a practical playbook)

1. Start tiny. One feature. One goal. One weekend.
2. Pick a friction-reducing stack (something you already grok).
3. Ship the core, then iterate. Release > perfect.
4. Keep the scope mercilessly small — scope creep is the silent productivity killer.
5. Learn, log, move on. Every project should teach one concrete thing (auth patterns, DB migrations, UX fail cases).

I use tiny experiments to test ideas: a two-hour prototype, a weekend MVP, then either a polish pass or a graceful sunset. The iteration rhythm matters more than the idea quality.

What I learn (and what compounds)

Each project teaches a micro-skill: state management patterns, deployment gotchas, API ergonomics, or the mental model behind a library. These micro-skills compound — they make the next project faster and better. It’s not just knowledge accumulation, it’s muscle memory.

Pull-quote: "Small projects are compound interest for craftsmanship."

The joy of shipping

There’s a real, weird joy in sending an update and watching one or two strangers use it. Shipping makes learning visible. It transforms private experiments into public signals.

Not about money (usually)

Monetization shifts intentions. Most of my side projects are intentionally non-commercial — they’re playgrounds, not startups. That freedom allows bolder choices.

TL;DR — TL;Funky (short, punchy, and actionable) 🚀

• Ship over polish. Try > theorize.
• Start tiny: one feature, one weekend.
• Learn one thing per project. Make it explicit.
• Keep scope small — scope kills experiments.
• Fail fast, log lessons, move on.
• If you want to build: start today and publish something imperfect.

If you build something, ping me. I love seeing experiments — drop a link, a weird bug, or a screenshot. Let’s trade notes and ship more weird, useful things. 🙌

— If you're curious about what I learned building Pomo, FitLog, or other small weirdos, check the rest of the blog. Or just start building. The rest follows.