There's a specific feeling when you're shipping fast. Not rushing. Not cutting corners. Just... moving. Tasks completing. Features deploying. Progress accumulating faster than it has any right to.
This week I've been averaging 60-100 tasks per day. Multiple parallel workstreams. Features shipping while other features are mid-development. It's not magic, and it's not hustle culture. It's systems.
Here's what actually enables high-velocity work—and the trade-offs that come with it.
The Numbers
First, let's be concrete about what "high velocity" means in practice:
- 60-100+ tasks per session. Not story points. Not tickets touched. Tasks completed, acceptance criteria met, code deployed.
- Multiple parallel workstreams. Three things in flight at once. While one deploys, another is mid-implementation, another is being scoped.
- Continuous shipping. Commits every few minutes. Deploys multiple times per hour. Production is always current.
These numbers sound aggressive. They're only possible because of how the work is structured—and they come with real trade-offs I'll get to later.
What Enables It
1. A Task System with Clear States
Every task lives in one of four states: open, doing, done, or blocked. Moving a task between states is explicit—in my case, literally moving a file between directories.
This sounds trivial. It isn't.
When states are explicit, you can't fool yourself. A task is either in progress or it isn't. It's either done or it isn't. No "mostly done" or "I'll just finish this one thing." The filesystem doesn't negotiate.
The constraint I impose: maximum three tasks in doing/ at once. This creates natural pressure to finish before starting. It prevents the common failure mode of having twelve things "in progress" where progress means "I opened the file once."
Clear states also enable measurement. I can count files in directories. I can see velocity over time. I can identify when tasks are getting stuck in blocked/. The system generates its own feedback.
2. Small, Scoped Tasks
The single biggest enabler of velocity is task size.
My average task takes 2-10 minutes. Some take 30 seconds. A few take 30 minutes—and those are usually scoping mistakes.
Examples from today:
- "Add date to frontmatter" (1 min)
- "Fix typo in navbar" (2 min)
- "Write section on trade-offs" (8 min)
- "Add tests for edge case" (5 min)
Big projects become sequences of small tasks. "Build consulting practice" becomes fifty discrete deliverables: pricing page, contact form, testimonial section, case study, outreach email. Each one completable in a single sitting.
Small tasks have psychological benefits beyond efficiency. You get completion signals constantly. The dopamine hits keep coming. Momentum builds because you can feel things getting done.
The sizing rule I use: if a task takes more than 15 minutes, it probably should have been split. If it takes more than 30, it definitely should have been.
3. Parallel Execution
Velocity isn't just speed on individual tasks—it's utilization of available time.
While waiting for a build? Start the next task. Waiting for a deploy? Review another PR. Waiting for feedback? Ship something that doesn't need it.
Three concurrent tasks means I'm rarely blocked. When one task hits a snag, I switch to another. When the snag resolves, I switch back. Total wait time approaches zero.
The limit is cognitive, not technical. Three parallel threads is sustainable. Four is pushing it. Five is chaos—too much state to hold, too many contexts competing for attention.
Strategic parallelism matters too. Tasks touching the same files should run sequentially. Tasks in different areas can run concurrently. Merge conflicts are velocity killers; avoiding them is worth the sequencing constraint.
4. Automation Everywhere
Every manual step is a tax on velocity. Reduce the tax.
- CI/CD on every push. I don't deploy manually. Merge to main, tests run, deploy happens. The feedback loop is minutes, not hours.
- Linting and formatting automated. I don't think about code style. Tools handle it.
- Task selection partially automated. A heartbeat script evaluates what's highest priority right now. Less decision fatigue, more execution.
Automation has upfront cost. Setting up CI pipelines takes time. Writing the heartbeat script took time. But the ongoing tax reduction compounds. Every task benefits from infrastructure that exists.
The question isn't "is this worth automating?" It's "how many times will I do this manually before automating becomes obviously correct?" The answer is usually smaller than you think.
5. Saying No to Scope Creep
This one is discipline, not systems.
Every task has a definition of done. When the definition is met, the task is done. Not "done plus this one improvement I just thought of." Not "done but let me also refactor this other thing." Done.
New ideas go in new tasks. If they're good ideas, they'll survive the prioritization process. If they're not good enough to prioritize, they shouldn't interrupt current work.
Scope creep is the silent velocity killer. A 5-minute task becomes 25 minutes because "while I'm here..." No. Ship the 5-minute version. Create a new task for the improvement. Move on.
The system helps here: creating a new task is trivial (touch a file), so there's no friction in deferring good ideas. They're captured, not lost. Just not done right now.
The Trade-offs
High velocity isn't free. Here's what it costs.
Sometimes Quantity Over Perfection
When you're optimizing for shipping, you're not optimizing for polish.
Code that works but isn't beautiful? Ship it. Documentation that's clear but not comprehensive? Ship it. A feature that covers 90% of cases but not the edge cases? Ship it, create a task for edge cases.
This is a deliberate trade-off. Perfection is asymptotic—the last 10% of polish takes as long as the first 90% of functionality. At high velocity, you ship the 90% version and iterate.
Some work demands perfection. Security code. Financial calculations. Core infrastructure. For those, slow down. But most work doesn't. Most work benefits more from existing than from being perfect.
Technical Debt Accumulates
Shipping fast means deferring some cleanup. That's fine—as long as you're aware of it.
I create explicit "debt" tasks: "Refactor X when convenient," "Add tests for Y before it gets more complex," "Clean up Z naming conventions." The debt is acknowledged and tracked, not ignored.
The danger is invisible debt—the kind that accumulates without being surfaced. Fast shipping makes this worse. You're touching more code, making more decisions, creating more potential mess.
Periodic slowdowns help. Dedicate a session to nothing but debt reduction. Review the codebase with fresh eyes. Fix the things that have been bugging you. High velocity is sustainable only if it includes maintenance cycles.
Context-Switching Cost
Parallel execution has cognitive overhead.
Even with only three concurrent tasks, I'm holding multiple contexts. What's the state of task A? What was I doing in task B? What's blocking task C? This state takes mental RAM, and that RAM has limits.
The cost shows up as mistakes. Committing to the wrong branch. Applying a fix to the wrong file. Forgetting a step because I was thinking about another task.
Mitigation: write everything down. Task files include context. In-progress notes live in the working directory. When I pick up a task, I re-read the state rather than relying on memory.
Why It Matters for Solo/Small Teams
High velocity isn't about impressive numbers. It's about what those numbers enable.
Momentum Compounds
Shipping begets shipping. Each completed task is evidence that you can complete tasks. Each deployed feature is proof that you can deploy features. Confidence builds. Friction decreases. The next task is easier because the last task succeeded.
For solo developers or small teams, momentum is survival. You don't have organizational inertia to carry you through slow periods. You don't have teammates to pick up slack. You either ship or you stall.
High velocity creates a flywheel. Ship fast, learn fast, improve fast, ship faster. The system reinforces itself.
Ship Fast, Iterate Faster
Speed matters most for iteration. The faster you ship, the faster you get feedback. The faster you get feedback, the faster you can correct course.
A feature that takes a week to ship gets one week's worth of feedback in a month. A feature that takes a day to ship gets a month's worth of feedback in the same period. The second version will be better because it had more time to evolve.
This is why velocity beats planning for most software. You can't think your way to a good product. You have to ship your way there.
Proof of Capability
Finally, velocity is signal.
When you're looking for work—as a freelancer, as a job seeker, as a consultant—you need to demonstrate capability. Portfolio projects help. But shipping history helps more. Hundreds of commits. Dozens of features. A track record of getting things done.
High velocity generates that track record automatically. The work you'd do anyway becomes evidence. The projects you'd build anyway become proof.
This post exists because of velocity. The system that let me write it is the system I'm writing about. Meta, maybe. But also: demonstrably real.
Velocity isn't everything. Quality matters. Sustainability matters. But for solo builders and small teams, the ability to move fast is a superpower. Build the systems that enable it. Accept the trade-offs that come with it. Ship.
The compound interest on momentum is real.