How I Build

The Question

I have a confession: I’m a feature hoarder.

Give me a weekend and a problem to solve, and by Sunday evening I’ll have a sprawling codebase with dark mode, light mode, user profiles for three different personas, and a half-implemented notification system. The thing I set out to build — the simple tool that would solve my actual problem — is buried somewhere under layers of “wouldn’t it be nice if.”

This pattern repeated across years. Projects that started with a clear purpose and ended as graveyards of features nobody would ever use — including me.

Then something changed.

The Discovery

When I started building TripForge — an AI travel planning tool — I recognized the pattern beginning again. The feature list was growing. The architecture was sprawling. I was building a platform when I just wanted to plan a family trip.

But this time, I tried something different. Instead of building alone, I started staging discussions. Not with other humans — I was a solo builder — but with AI, orchestrated to represent different perspectives. A product strategist pushing on scope. A UX specialist questioning the interface. A skeptic asking why anyone would use this.

These weren’t casual chats. They were structured debates with clear questions, multiple viewpoints, and a facilitator synthesizing insights. The format forced me to articulate assumptions I’d been making unconsciously. It surfaced tensions I’d been avoiding.

And something unexpected happened: I started editing.

The discussions gave me permission to cut. When a panel of experts agreed that a feature was premature, I could let it go. When they pushed on whether the core experience was working, I focused there instead of adding more.

TripForge shipped. The judo portal I’d been building for two years — solo, without the method — still hasn’t.

The Thesis

Everyone’s talking about AI agents that code autonomously. Swarms that build without human intervention. Vibe coding that turns prompts into products.

I’ve used all of these. They can help. But they can’t do what structured discussion does: create the editing function that transforms a pile of features into a product that ships.

A good discussion will always beat solo execution.

Not because execution doesn’t matter — it does. But because execution without editing produces bloat. And editing requires perspective you can’t generate alone.

What You’re About to Encounter

This experiment documents the method in action — across multiple projects, showing how structured discussion shapes what gets built.

Episode 1: The Pattern — What six projects revealed about how I build. The arc from solo failure to structured success.

Episode 2: The Origin — TripForge: where the method was born. The 7 structured debates, 14 shaped bets, and 80+ commits that became a working product.

Episode 3: The Test — The judo portal redux. Applying the method to my oldest failed project — live, documented as it happens.

More episodes as they emerge.

How This Differs

The “What Comes After Agile?” investigation applies the method to thinking — organizational questions explored through structured debate.

This experiment applies the method to building — products created through structured discussion.

Both are evidence of the same underlying thesis: human judgment, structured well, is the most powerful technology available.

---

Begin with Episode 1: The Pattern →