Planning vs. Building: Finding the 80/20 for Solo Founders

"Just ship it."

That's the prevailing advice for founders. Stop planning. Stop overthinking. Get something out the door and iterate.

I used to believe this. Then I watched three months of work get thrown away because I'd built the wrong thing fast.

Now I believe something more nuanced: spec writing is building, done early.

In a world where AI can generate code faster than you can review it, the bottleneck has shifted. The scarce skill isn't coding anymore—it's knowing what to build and describing it clearly enough that AI gets it right the first time.

But there's a trap on the other side too. Planning can become productive procrastination—the feeling of progress without actual progress.

This post is about finding the balance.

My Actual Time Split

After nearly two months of building Kodebase—where AI writes the code and I orchestrate—here's how my time consistently breaks down:

Look at that. 35% of my time goes to writing specs. <1% to actual coding.

If you'd told me this ratio before I started, I would have said you were crazy. Planning should be maybe 10%, right? Get in, describe it, go.

I was wrong.

Why Spec Writing Takes More Than You Think

Here's what a good feature spec actually requires:

1. Clear summary — What are we building and why? (5 min)
2. Success criteria — How do we know it's done? (15-30 min)
3. Edge cases — What could go wrong? (10-20 min)
4. Integration points — How does this connect to existing systems? (10-15 min)
5. Validation steps — How does a human verify this works? (10-15 min)

A simple feature takes 10-15 minutes. A complex one might take 45 minutes. A full initiative—multiple related features planned together—can take 2+ hours.

This feels slow. It feels like you're not making progress. The urge to skip steps is overwhelming.

But here's the math: 45 minutes of clear spec writing saves 3-4 hours of rework when the AI builds the wrong thing. I've tested this. The ratio holds.

The magic is what happens next. With Kodebase, Scout validates your spec against business context before any code gets written. It catches ambiguity, missing edge cases, and conflicts with existing systems—the exact problems that cause expensive rework downstream.

The Trap: Productive Procrastination

Planning is seductive because it feels like work.

You're thinking hard. You're writing things down. You're making decisions. At the end of a planning session, you have a document—proof of progress.

But planning has diminishing returns. At some point, you're not clarifying requirements—you're avoiding the scary moment when you have to commit to building.

Signs you've crossed the line:

• You're on your third revision of success criteria that were clear the first time
• You're researching edge cases that have a 0.1% chance of occurring
• You're writing documentation for features that don't exist yet
• You've spent more time on the spec than the implementation will take

I catch myself doing this. The planning phase feels safe. Hitting "go" and letting AI execute exposes you to the reality of whether your spec was actually clear.

My Rules of Thumb

After a lot of trial and error, here's how I decide when to stop planning:

Rule 1: The "Fresh Eyes" Test

Could someone who has never seen this project understand what you want built from your spec alone?

If yes, you're done planning. If no, you're missing context.

This doesn't mean exhaustive documentation. It means sufficient clarity. The AI needs the same context a new team member would need.

Rule 2: The 2-Hour Cap

No spec should take more than 2 hours to write. If it does, the scope is too big. Split it.

Large specs are a sign you're trying to solve too many problems at once. Each spec should be one coherent thing.

Rule 3: The "What Could Go Wrong" Limit

List three ways this feature could fail or be misunderstood. Address those in the success criteria.

Not thirty. Three. The most likely ones. Obsessing over every possible edge case is procrastination disguised as thoroughness.

Rule 4: Ship the Uncertainty

Some questions can only be answered by building. If you've been debating an approach for 30+ minutes, pick one and commit.

Wrong decisions made quickly are better than right decisions made slowly. You can fix code. You can't fix time.

The Daily Balance

I don't work in neat time blocks. I don't "sit down to code." I run multiple Kodebase instances in parallel while doing founder work:

Instance 1: Planning & Strategy

Specs, roadmaps, initiatives. Marketing copy. Social media. Sales calls. Beta user feedback. This is the founder work—and it happens while AI is building.

Instance 2: Execution (AI-driven)

Work is always running here. AI executes validated specs. I check in periodically, review PRs when they're ready, and merge what passes review. Then I go back to whatever I was doing.

The key insight: I'm not a developer who also does founder work. I'm a founder who orchestrates AI. While one feature is being built, I'm on a sales call. While another PR is running tests, I'm writing a blog post. The constraint isn't my coding speed—it's how fast I can think clearly about what to build next.

When Planning Matters Most

Not all features need equal planning. Here's my rough calibration:

Heavy planning (45+ min per spec):

• Core architecture decisions
• Features that touch multiple systems
• Anything involving data models
• Security-sensitive functionality
• User-facing flows with many states

Medium planning (20-45 min):

• Standard CRUD operations
• UI components with clear requirements
• Integrations with documented APIs
• Bug fixes with known root causes

Light planning (10-20 min):

• Documentation updates
• Style/formatting changes
• Configuration tweaks
• Refactors with clear patterns

I've been burned by under-planning architecture and over-planning config changes. Calibrate to risk.

The Meta Question: Planning the Plan

Before any project, I spend time planning the plan:

1. What's the scope? What does "done" look like for the whole project?
2. What are the major phases? Group features into logical batches.
3. What has to go first? Dependencies and sequencing.
4. What's the riskiest part? Do that early.
5. What can I cut? Pre-identify the features that might get dropped if time runs short.

This meta-planning takes half a day for a big project. It prevents the chaos of discovering mid-sprint that you're building in the wrong order or missing critical dependencies.

The Honest Truth

I still get the balance wrong sometimes.

Some days I plan too much, seduced by the comfort of documentation over hitting "go." Some days I approve PRs too fast, letting sloppy implementations through that cost days to fix.

The goal isn't perfection. It's awareness. Know when you're planning productively vs. procrastinating. Know when you're shipping vs. rushing.

Within development time specifically, my ratio is roughly: 70% planning, 30% reviewing. That felt absurd until I saw the results—features ship faster with fewer bugs when the spec is bulletproof. And that 30%? It's not coding. It's reviewing what AI built and deciding if it's good enough to merge.

Your ratio might be different. But if you're spending less than 50% of your dev time on planning, you're probably shipping rework. And if you're spending more than 80%, you're probably shipping fear.

Spec writing is the new superpower. Master it, and AI becomes your force multiplier. Skip it, and you're just generating expensive garbage faster.

Find your balance. Then trust it.