You spend time up front to find them. With a few hours of up-front work it's not very difficult.Well, but upfront I don't even know the tasks that may crop up in the future. And once I encounter them I can often not be sure whether they're one-off or recurring. I just don't see how this is any quicker (or different, tbh) to just finding people when you need them - and hiring them or contracting to them.
The author apparently wants me to avoid hiring people and contract out everything instead. I have never seen that work on such a fine-grained level.
I'd need a PA just to spend the time of finding and managing all those micro-contractors.
But that doesn't mean outsourcing is bogus, or that it doesn't work.
Well, I didn't say it wouldn't. I'm just saying it was quite overhyped for a while ("just outsource everything to India") and this article seems to beat that dead horse again, from a slightly different angle.
We've outsourced post-launch bugs to a very talented developer who works for us 2-8 hours per week depending on the bugs we find.
Sorry, but that sounds absurd to me, unless your app is of the truly trivial kind. Bugfixing normally requires a deep understanding of the codebase and is exactly the kind of work that makes not much sense to outsource.
And how is a "post-launch bug" different from a "pre-launch bug", btw?
If you're working on a credit card processing system you are correct due to the complexity. But most apps are not this complex, and you'd be surprised how quickly a solid developer can start fixing bugs on a system they've never seen before if they are talented and the architecture is sound.
If it's honestly cheaper to have an external contractor learn your codebase and fix your bugs, than to have your in-house staff take care of that, then I think you have much bigger problems in first place.