One thousand projects. Five years. Working alone. That is roughly one shipped project every two days, sustained, with no team to hide behind. When I say that number out loud, people assume one of three things: it is a lie, there is a hidden agency, or the work must be garbage.
It is none of those. It is a system - a small set of unglamorous habits that compound. And unlike most "productivity" advice, this one was forged under real deadlines for real paying clients, not in a notebook. Here is the whole thing, honestly, including the parts that did not work. Steal what is useful.
First, the math nobody believes
Five years. Around 200 projects a year. Some were thirty-minute fixes; others were month-long platform builds. The average is meaningless - the point is what the volume forces you to become. At that pace you cannot afford waste, ego, or heroics. You are forced into focus, reuse, and brutal honesty about where your time actually goes.
| The habit | What it kills |
|---|---|
| Reusable libraries | Reinventing the wheel |
| Ruthless scope | Endless rework |
| Deep work blocks | The context-switching tax |
| AI as accelerator | Slow typing, not slow thinking |
| Ship, then harden | Perfectionism that never ships |
System 1: A library, not a blank page
After a decade in WHMCS, hosting and web, almost nothing I build is truly from scratch. I have battle-tested patterns for provisioning modules, payment gateways, hooks, WordPress hardening, server setups and deployment scripts. A "new" project is usually 70% assembling proven pieces and 30% adapting them to the client.
The lesson is bigger than code: your second version of anything should never cost as much as your first. If it does, you are not saving your work. Build your own library - of code, of checklists, of email templates - and every future project starts at the 70% line.
System 2: Scope discipline (the real time-killer)
The fastest way to finish is to know exactly what "finished" means before you start.
Most developers do not lose weeks to hard problems. They lose them to moving problems - "while you're in there, can you also..." I agree scope in writing, every time. Not to be difficult, but because an undefined finish line is the single most expensive thing in software. Changes are welcome; they just become the next, clearly-scoped piece of work rather than silent additions that quietly eat the budget.
System 3: Deep work, zero context-switching
Context-switching is the silent tax on output. Every time you jump between projects, your brain pays a reload cost - and ten half-finished things in your head is the natural enemy of shipping. So I batch similar work and protect long, uninterrupted blocks. I take a project from understanding to done before opening the next one. Fewer things in flight, more things finished.
If you take one thing from this article, take this: finishing is a skill, and it is mostly about refusing to start the next thing too soon.
System 4: AI as an accelerator, not an autopilot
Since AI tooling matured, my throughput jumped again - but not the way people fear. I do not generate code and pray. I use AI to write faster while I steer the architecture, read every line, and test the edges. The judgment is mine; the typing speed is borrowed.
This distinction is the whole reason the work still holds up in production. Generated code that nobody understands is a liability with a delay timer on it. Code written with AI, by someone who knows what good looks like, is just senior work delivered faster. I wrote a whole piece on building with AI the right way if you want the deeper version.
System 5: Ship, then harden
I get to a working, tested result quickly - then I harden it: security, edge cases, documentation. The order matters. A shipped, solid thing that you improve beats a "perfect" thing that never launches. Momentum is a feature. Perfectionism, left unchecked, is just procrastination in a nicer outfit.
The parts that did not work
I will not pretend it was all clean. Early on I:
- Said yes to everything - and learned that the wrong project costs you two: the bad one, and the good one you were too busy to take.
- Under-charged for deep work - racing to volume taught me that price and care must rise together, or quality quietly slips.
- Skipped documentation once or twice - and paid for it the day a client came back and I had to re-learn my own work.
The system above is partly a list of those mistakes, inverted.
Steal this: the five-line version
- Build a personal library so version two is cheap.
- Define "done" in writing before you touch the keyboard.
- Protect deep blocks; finish one thing before starting the next.
- Use AI to type faster, never to think for you.
- Ship, then harden - momentum over perfection.
What this means if you hire me
A thousand projects taught me one thing above all: clients do not want activity, they want outcomes, delivered. You get senior judgment at a pace a small team would envy, one point of contact, and a developer who has very probably seen your exact problem before. If that is what you need, tell me what you are building.
