Atomic Planning: How We Ship 121 Commits in 4 Days

The 4-Day Build

eComX — this website — went from an empty directory to a fully functional Next.js 15 application in 4 working days:

• February 23: Foundation (1 commit — project initialization)
• February 24: Foundation complete + Core Pages (28 commits)
• March 4: Conversion Layer complete (47 commits)
• March 5: Content & Proof complete (45 commits)

121 atomic commits. 4 phases. 28 plans. Zero build failures in production. Every commit traceable to a specific task in a specific plan.

This isn't hustle culture speed. It's planning discipline.

What "Atomic" Means

An atomic plan is the smallest unit of work that produces a verifiable, committable result. It has five properties:

1. Independently Completable: Can be finished in one session without depending on unfinished work
2. Verifiable: Has specific acceptance criteria that can be tested
3. Committable: Produces code that builds and passes TypeScript checks
4. Documented: Generates a summary explaining what was done and why
5. Reversible: Can be rolled back without affecting other plans

The opposite of atomic planning is "just start building." That approach works for small projects but collapses at scale. When you have 10 interconnected features, building without plans means discovering dependency conflicts at 2 AM when you're three features deep and can't roll back any of them.

Phase 3: A Deep Example

Phase 3 (Conversion Layer) demonstrates the methodology at its most demanding. The phase objective: build payment infrastructure, email sequences, authentication, analytics, and form security.

Before Anything: Discuss

/discuss-phase produced 03-CONTEXT.md — a document that resolved 6 gray areas before any plan was written:

• Should we use Stripe Checkout or embedded Payment Elements? → Payment Elements (more control, better UX)
• Cookie-based auth or Supabase Auth for debug dashboard? → Cookie-based (simpler, no user accounts needed)
• How do we handle email sequencing without a dedicated job queue? → Vercel Cron + database state machine
• CSRF protection approach? → Double Submit Cookie pattern with per-route tokens

Each decision included rationale and alternatives considered. When the plans reference these decisions, there's no ambiguity — the discussion already happened.

Then: Plan

Eight plans were generated, each with explicit task breakdowns:

Plan 01: Stripe Products and Payment Intents

• Task 1: Install Stripe SDK, configure environment variables
• Task 2: Create product creation script with full pricing ladder
• Task 3: Build payment intent API route with comprehensive error handling
• Task 4: Write client-side payment form component
• Task 5: Add server-side payment verification
• Acceptance: Payment flow works end-to-end with test credentials

Plan 02: Resend Email Infrastructure

• Task 1: Install Resend SDK, configure sender identity
• Task 2: Build React Email templates (welcome, receipt, sequence)
• Task 3: Create sendEmail utility with retry logic
• Task 4: Build audience management API route
• Acceptance: Test email sends and renders correctly in major clients

Plans 03-08 followed the same pattern. Each plan built on the previous one — email infrastructure needed Stripe (for receipt emails), auth needed Resend (for verification emails), sequences needed both.

After Plans: Gap Analysis

/analyze-gaps reviewed all 8 plans against the phase context and found gaps:

• Gap 1: No CSRF protection in form submissions → Added to Plan 07
• Gap 2: No rate limiting on payment intent creation → Added to Plan 01
• Gap 3: Webhook signature verification missing → Added to Plan 02
• Gap 4: No error boundary for payment failures → Added to Plan 04

Four gaps caught before a single line of code was written. Fixing them in the plan took 10 minutes. Discovering them during execution would have taken hours of debugging and refactoring.

Execute: Plan by Plan

Each plan was executed in sequence:

Plan 01: Stripe → commit → summary
Plan 02: Resend → commit → summary  
Plan 03: Auth → commit → summary
Plan 04: Sequences → commit → summary
Plan 05: Post-Purchase → commit → summary
Plan 06: Analytics → commit → summary
Plan 07: Form Security → commit → summary
Plan 08: Verification → commit → summary

47 commits total. Each commit message references its plan number: feat(03-01): Stripe product catalog and payment intents. Each plan produced a SUMMARY.md documenting what was completed, what deviated from the plan, and what the next plan should know.

Deviations Are Normal

Not everything goes to plan. Phase 3 had documented deviations:

• Plan 01 deviation: Stripe SDK types required TypeScript config adjustment (moduleResolution: "bundler") — not anticipated in the plan, documented in summary
• Plan 04 deviation: Vercel Cron's minimum interval is 1 minute, not 30 seconds — sequence timing adjusted accordingly
• Plan 07 deviation: CSRF double-submit pattern required middleware changes that affected all API routes — scope was larger than planned

Each deviation was documented in the plan's SUMMARY.md with three things: what happened, why it happened, and how it was resolved. This deviation log is gold for future projects — it's a record of what goes wrong in real builds, not a theoretical list of potential risks.

The Compound Benefit

After 28 plans across 4 phases, patterns emerge:

1. Plans get better: Phase 4 plans were more precise than Phase 1 plans because the planning workflow had learned from previous phases
2. Gap analysis gets sharper: Phase 4's gap analysis caught subtler issues because it had 3 phases of gap history to learn from
3. Summaries get more useful: Later summaries anticipated what future plans needed to know, creating a forward-looking documentation style
4. Commit discipline improves: Early commits were occasionally too large; later commits were consistently atomic

Why This Produces Speed

Counterintuitively, the extensive planning overhead (discuss, research, plan, analyze gaps) produces faster total delivery time:

• No backtracking: Dependencies are mapped before building. You don't discover in Plan 6 that Plan 2 was built wrong.
• No decision paralysis: Gray areas are resolved in the discussion step. During execution, you build — you don't debate.
• No debugging spirals: Gap analysis catches issues before they become bugs. The most expensive debugging never happens.
• Parallel clarity: Clear task breakdowns allow AI agents to execute with minimal human oversight. I review, approve, and redirect — I don't micromanage each line of code.

The Phase 3 discussion took 20 minutes. Planning took 30 minutes. Gap analysis took 15 minutes. That's 65 minutes of overhead. Execution took 6 hours and produced 47 commits — 8 features, zero rollbacks, zero build failures.

Without planning, the same work might take 10+ hours with multiple rollbacks, several builds failures, and at least one moment of "wait, I should have designed this differently."

The Living Record

The .planning/ directory is now the most complete development journal I've ever produced. It contains:

• Every decision and its rationale
• Every plan with task-level detail
• Every gap caught before execution
• Every deviation and its resolution
• Every summary with lessons learned
• Every commit tied to a specific plan

When someone asks "how was eComX built?" — the answer isn't a vague story. It's a structured, searchable, verifiable build record that anyone can read, learn from, and replicate.

That's the difference between building software and building a system for building software.