[byoung2]

There is much time spent creating detailed specs, clarifying the specs, reviewing delivered code then immediately demanding key improvements made to that code, replacing subpar developers

One could argue that this time would be well-spent even if your development team is in-house. The convenience of having all of your developers sitting in one room with you often leads to laziness and sloppy project management. When the customer service guys can approach an in-house developer immediately with a bug a customer reported, sometimes the bug gets fixed, committed, and deployed right away with no documentation. This makes for a great experience for that customer, and management can pat themselves on the back and call their team "agile" but imagine the alternative scenario.

Say that customer service rep has to create a detailed bug report with screenshots and steps to reproduce the error, and in the middle of the night (because of timezones) your outsourced dev fixes the bug and completes a post-mortem to close the ticket before committing and deploying. This leads to more organized processes, better documentation, etc.

[swombat]

That's exactly the point snorkel is making. You can get all that documentation, but that costs velocity.

For an early startup, velocity is way, way, way more important than clear documentation. When you're sitting with a rapidly shrinking runway and no viable business model, writing a spec, post-mortem, or documentation for a bug is a total waste of your precious, limited resources, like doing lunges when you're running out of air.