There are some really good points here to make us think about meetings, decision making, and scheduling. The arguments are valid, but I’d like to add perspective from the other side of things.

I’ve done several years of solo projects, in addition to a dozen years working in corporate teams, and during this time have also observed output from contractors. Most of the top 10 thing’s I’ve learned which I believe makes a great programmer came from working on a team.

I’m definitely not here to crap on contractors or freelancers, though I have seen a recurring pattern in work that gets done fast by a single developer. Sometimes the contractor doesn’t see the problems felt by the team who has to maintain the contractor’s code for years after they’re “done”. Whether the problem is lack of tests, no automation, heavy use of “temporary” hacks, or too basic architecture (similar to that of demo/tutorial code), or all of the above, it costs the customer a lot of time and money to work with it afterwards.

To their credit, not all solo developers cut corners or produce high technical debt, and some of them may even have better practices than team developers. Some team developers have these issues too, on teams with no technical leadership. At least in teams there is more chance of influencing good behaviour.

Faster isn’t always better. My advice to freelancers or contractors is to learn the how and why of the best practices used by development teams, then learn to apply this to solo work – where it makes sense to do so – but without making excuses not to. Being faster may be cost-effective for you, but not always for the company who hired you.