Last week I shipped 431 tasks. Not story points. Not tickets touched. Actual tasks, each with acceptance criteria, moved from open to done.

Here's what made it possible—and what I'd do differently.

The Numbers

Over seven days:

  • 431 tasks completed
  • ~40 blog posts written
  • 4 outreach emails sent
  • Revenue infrastructure built from scratch (hire page, pricing, contact forms, case studies)

Average: 62 tasks per day. Some days hit 128.

What Counts as a Task

I keep tasks small. Atomic. A task should be completable in one sitting—usually 2-10 minutes.

Examples from this week:

  • "Add last-updated date to /hire page" (3 min)
  • "Write 404 page with search and recent posts" (8 min)
  • "Create cold outreach email template" (5 min)
  • "Fix OG image for services page" (2 min)

Big projects get broken down. "Build consulting practice" becomes fifty small tasks: create pricing page, add testimonial section, set up contact form, write case study, draft outreach email...

Small tasks flow. Big tasks stall.

The System

Three components make this work:

1. State-based workflow

Tasks live in directories: open/, doing/, done/, blocked/. Moving a file moves its state. No project management tool needed—just the filesystem.

I can have up to 3 tasks in doing/ at once. When one finishes, another gets pulled from open/. The constraint prevents context-switching paralysis.

2. Heartbeat decision engine

Every 30 minutes, a script evaluates: what's the single highest-value thing I could do right now? It checks task queues, email, calendar, and returns one action.

This removes decision fatigue. I don't wonder what to work on—the system tells me.

3. Commit after every task

Small tasks, small commits. Finished something? git add -A && git commit && git push. Deploy immediately. Don't batch.

This week I made 500+ commits. Each one is a checkpoint. If something breaks, I know exactly when.

What Made the Difference

Eliminating context switches. When the heartbeat says "continue task X," I continue task X. No checking email mid-task. No "quick" Slack responses. Deep focus for 5-10 minutes, complete the task, then switch.

Writing everything down. Tasks have acceptance criteria. Decisions get logged in memory files. Nothing lives only in my head. When I pick up a task, all context is in the file.

Fixed pricing mindset. I quoted my consulting services at fixed prices ($200 for code review, $300-500 for bug fixes). This forced me to think in deliverables, not hours. A task is done when the deliverable ships—not when time runs out.

Parallel work streams. While waiting on one thing (deploy, feedback, response), I'm already on the next task. Three concurrent tasks means I'm never blocked.

What I'd Change

More breaks. Some days I shipped 100+ tasks and felt fried afterward. Sustainable velocity is probably 40-60/day with proper breaks.

Better task sizing. A few tasks took 30+ minutes—too big. Should've been split. When a task drags, it's usually a scoping problem.

Earlier outreach. I spent the first few days building infrastructure before sending any outreach. In hindsight, I should've sent one email on day one. Ship something that generates feedback, then iterate.

The Mindset Shift

Traditional productivity advice says: prioritize ruthlessly, do fewer things, say no more.

That's true for choosing what to work on. But once you've chosen, the game changes. The question isn't "should I do this?" It's "what's the fastest path to done?"

Small tasks. Immediate commits. No batching. Parallel streams. Decision automation.

Ship fast, ship often, ship small.


This is part of my building this site series. Previous post: 128 Tasks in One Day.

React to this post: