Seven Rabbit Holes, Three Countries

After work again, I open the laptop. The terminal's black screen greets me.

A few months ago, this screen was unfamiliar. I'd stare at white text blinking on a black background and think, "What can I possibly do here?" Now I still can't read code, but the screen doesn't scare me. Red text appears and I don't flinch. Not because I know what the red text says, but because I know that if I send it to someone, an answer comes back.

Building one service took weeks. Days writing design documents, days building V2, days discovering V2's structure was flawed, more days rebuilding as V3. Deploying, fixing errors, integrating payments. Along the way, learning terminology, choosing tool combinations, developing the skill of directing AI.

But the service I want to build isn't just this one.

Seven services stand before me. Each needs to launch in three countries—Korea, Japan, and the English-speaking world. Seven times three is twenty-one. Logically, twenty-one launches.

When I first faced this number, it felt, honestly, unrealistic. Building one took this long, and I'm going to build twenty-one?

But while drafting the master plan with AI, I realized: it's not as unrealistic as the number suggests.

The key is that everything learned building the first service applies from the start of the second.

The V2-to-V3 refactoring produced six lessons. Missing database tables. Module interface mismatches. Absent user IDs. Hardcoded configuration values. Missing auth settings. Environment variable inconsistencies. These six go into the checklist from day one of the next service. No need to make the same mistake twice.

The "control tower + builder" workflow is already established. Same structure, every new service.

The cost modeling methodology exists too. Per-model token pricing, per-language token multipliers (Japanese is roughly twice English), user-count-based cost simulations. Directly applicable to the next service.

I collected all of this into a "development playbook." A procedure manual for starting new services. Phase 0: answer seven questions before writing a single line of code. Phase 1: create five design documents. Phase 2: build core modules in sequence. The fumbles from StackTube are this playbook's raw material.

The master plan document reached 751 lines. Written in one day with AI. Seven services, each defined: revenue structure, tech stack, cost simulation, country-specific differentiators, launch sequence, kill criteria.

Kill criteria—a line that triggers project termination. "If, within twelve weeks, we don't reach 100 users or $200 monthly revenue—stop." I set this without emotion. Setting a termination threshold for a service that hasn't even launched might seem strange. But without it, you pour endless time into failed projects. For someone with only evenings, time is the most expensive resource.

I also asked AI whether we could apply an agent harness structure—a three-stage automation where AI autonomously plans, generates, and evaluates. The control tower's answer: "Possible, but premature. Building excessive automation before launch means spending time debugging the automation."

I accepted this advice. Listening when AI says "don't" is also a PM's job.

Looking back, what I learned on this journey wasn't coding.

Errors are hints, not failures. Toggle, URL, setting—most are this level. Planning comes before code. AI is a capable junior, not a wizard. Whether AI's answer is correct—that's mine to verify.

And when time is scarce, there's less room for mistakes. So people with only evenings become, paradoxically, more strategic.

The first result of this journey got a name: StackTube. Stack means to accumulate. Tube is YouTube. A pipeline for stacking scattered video knowledge. What I wanted in Episode 1—a tool that answers "what have I learned about this topic in the past two weeks?"—that's what this is.

It's not perfect. The design looks AI-generated. Error handling isn't smooth everywhere. But the core works. Register channels of interest and when new videos appear, they're automatically analyzed. Cross-reference knowledge across multiple videos.

If you've built it, you should ship it. "A launched product beats a perfect product"—I've heard this said plenty, but actually pressing the launch button is a different matter entirely. Asking someone "want to try what I made?" is a type of courage I'd never exercised before.

Someone asked me, "How long are you going to keep doing this?"

I don't know, honestly. But every night at nine when I open the terminal, I sense that I'm fumbling a little less than yesterday.

And I think that's a pretty decent kind of progress.

---

🔧 Technical Terms in This Episode

MRR (Monthly Recurring Revenue) Revenue that repeats every month. The core metric for subscription models. Not "this month's sales" but "money that reliably arrives every month."

Kill Criteria A predetermined threshold for stopping a project. Set with numbers, not emotions. "If we can't reach 100 users in 12 weeks, we stop." Without it, you endlessly invest time in failed projects.

Playbook A reusable execution manual. From American football—a rulebook of "in this situation, do this." Turning StackTube's experience into a playbook prevents repeating the same mistakes in the next service.

Agent Harness An AI automation structure composed of Planner (plans) → Generator (creates) → Evaluator (validates). Currently the human serves as both Planner and Evaluator, but the ultimate goal is AI performing all three roles.

Token (AI cost context) The smallest unit AI uses to process text. Roughly one English word ≈ 1 token; one Korean character ≈ 1–2 tokens; Japanese consumes about 2× the tokens of English. API costs are proportional to tokens processed.

SSO (Single Sign-On) A structure where one login grants access to multiple services. Like using one Google account for Gmail, YouTube, and Drive simultaneously.