What I Learned From the One Time I Hired Help (And Why I Went Back to Solo)
I brought on a contractor for a few months, for reasons that made sense at the time. Here's what actually happened, and why I ended up back to running everything solo.
I've written a lot about running six products alone. What I haven't written about is the one stretch where I didn't, when I brought on a contractor for a few months to help with a specific backlog that had gotten genuinely out of hand. It didn't fail in any dramatic way. I just ended up back to solo afterward, and the reasons are more specific than "it didn't work out."
Why I Brought Someone On
The backlog for one product had grown past what I could clear in a reasonable amount of time, and a lot of it was genuinely well-scoped, bounded work: bug fixes with clear reproduction steps, small feature requests with an obvious shape. That's the kind of work that looks perfect to hand off, and on paper it was a sound decision.
What Actually Happened
The work got done. The contractor was competent, communicative, and delivered what was scoped. The backlog cleared. By every metric I'd have used to judge the arrangement going in, it worked.
What I didn't account for was everything that happens around the actual ticket. Reviewing pull requests for someone else's mental model of the codebase took real time, more than I'd budgeted, because I was checking not just "does this work" but "does this match the assumptions the rest of the app is built on." Answering questions about context that lived only in my head added a second, ongoing cost that never showed up on the original scoping estimate.
The Part I Actually Underestimated
The tickets I handed off were the well-scoped ones precisely because they were easy to hand off. That meant I kept the ambiguous, judgment-heavy work for myself, which is exactly the work that benefits most from someone thinking about the whole product at once. Splitting the backlog this way didn't reduce my cognitive load the way I expected. It just changed what kind of load I was carrying, from "too many tickets" to "context-switching between my own hard problems and reviewing someone else's solved ones."
Why I Went Back to Solo
Once the backlog was clear, I looked at whether to keep the arrangement going for ongoing work, and the honest answer was that the review and context overhead was costing me close to what the contracted hours were saving me. Not because the contractor did anything wrong. Because the actual bottleneck in running six products by myself was never "not enough hands doing tickets." It was context living in one head, and handing off tickets doesn't hand off the context that makes reviewing them fast.
What Would Make Me Try Again
This isn't a permanent verdict against ever hiring help. It's a specific verdict against handing off bounded, well-scoped tickets as the entry point, because that's the type of work where the review overhead eats the savings fastest. If I bring someone on again, it'll be for something with a genuinely separable scope, a whole feature or a whole surface of the product, where the context transfer is a one-time cost instead of a recurring one on every single ticket.
The Bottom Line
Hiring help didn't fail because the person wasn't good. It didn't match the actual shape of the bottleneck I had, which was concentrated context, not raw ticket volume. Clearing a backlog and reducing my actual workload turned out to be two different problems, and the arrangement solved the first one while quietly adding a new version of the second.