> For instance, micro services and an extremely complex distributed architecture will add a lot of overhead and points of failure when a monolith is probably the best route when you have a few engineers.
But micro services will be a lot easier to get right and test.
No, but I've built at least one project where I'm 100% sure that if we had not chosen the 'micro service' path we'd never have completed it at all. Mind you, this was in the early 90's and we called them administrators but the end result was much the same. Easy to understand components fit together with lightweight glue.
That project was exactly that, fast startup with 3 programmers, one of who was doubling as the tech guy. It made a few hundred million and it is still running today in more or less unmodified form (it's a bit prettier now, but the essence remains).
Monolithical development has a fairly low ceiling of complexity before you drown.
Separating things into components is great, at least in-process where you can enforce interfaces with compilers. Managing deployment, versioning, and compatibility of 10's of networked services (aka micro services) is not a good way to spend time in a young startup...
Of course, one monolith is a bad idea. Probably need a handful of services -- especially separating long running background work from foreground work, glued together with a queue system.
But micro services will be a lot easier to get right and test.