Not having team of six can be alleviated by setting realistic expectations.

If you hire 1 or 2 devs and one gets sick don't expect other one not to take vacations he planned 2 months ago.

It will hit your bottom line but that is the risk you will have to eat as an owner and not your employees.

Manager at big.co usually does not have option to "eat a risk" so he should put preventative measure for such a scenario.

If you hire 1 or 2 devs and one gets sick don't expect other one not to take vacations he planned 2 months ago.

Right, in that case, I'd probably give up my vacation instead.

Why does anyone have to give up a vacation?

Unless you're building intelligence or defence software or something like that.

When you're have a small company you're hoping to turn into a larger one, many deadlines are every bit as existential as a DoD proposal deadline for a defense contractor. Especially when you don't have a big slosh pool of VC funding (but this is largely true even if you do), the difference between "stable and growing at a healthy pace" and "if something doesn't change we'll have to shut down" is often one or two customers.

This is only a feasible plan for people without any children or committed relationships though. Telling your spouse that you'll skip the vacation because work is more important than them will not go over well, for obvious reasons.

Or keep deploying daily anyway so when everyone is out the production env. is pretty up to date and undeployed feature inventory low.

I work in a small company, and we have a team of 3, if you count liberally. One colleague does front-end stuff, there is a tester who is intimately familiar with the way the software is used, I do the rest. That's really enough for the moment.

Currently at my company I'm the only one dev. Advantages and disadvantages, but having all code at one head really simplifies communication overhead.

I hope I keep complexity sufficiently down so we won't need more than 2 or 3 more engineers.

What's the plan for if you get hit by a car and can't work anymore?

There's a huge difference between a team of 6 full-stack developers and a modularized team where everyone has their own projects.

Six is where you start figuring out how you're going to split the team. Eight is where you actually make it happen (either into 4+4 or 6+2).

Agreed. Teams that are any bigger than that inevitably run into communication problems. Small teams are good for close cooperation. Big teams are good for wasting time.

Growing your team too fast will always result in integration problems. Both quality and culture wise.

Quality can be enforced by tooling somewhat (automatic formatting, enforced linter rules in CI etc.), but culture takes time.