I'd recommend the opposite. Learning tons of 3rd party tools and relying on multitude of external dependencies is dangerous, especially when company can't afford sudden downtime or security breaches. For simple enough tasks, like many those tools on the market are solving, it's arguably better to create a tailored version in-house than to learn the approximation from the market, then spend resources associated with long-term costs - upgrades, learning, payments...

Focusing on business problems is good and all, but if you're ruthlessly outsource everything else, you'll find yourself in the middle of patchy solution with little control and no end of gotchas - technical and otherwise. If you plan to use 10% of a tool and going to pay for 100%, for startups it should be a no-brainer decision.

If you can’t afford downtime and security breaches, you can’t afford to be shipping an amateur and half baked version of something that externally is backed by a bigger and more skilled team than your entire engineering org. You can potentially simplify your approach so you don’t need anything in the category.

There is always going to be some nuance. But there is a big difference between implementing your own database and implementing your own deployment script. Starting out small and adding tools to your toolbox is going to be a judgement call. But too much NIH and you spend all your time reimplementing Bigtable or Cockroachdb instead of building your product.

True. It's just my observation that today's approach is mostly "let's focus on our value proposition and outsource everything else" to the degree it becomes detrimental for the product and company.

Surely if you're trying to re-implement PostgreSQL, it's, to put it mildly, interesting (though even here there could be discussions - perhaps you just need a specific slice of functionality?). But for many, many other things, which are at worst a few man-weeks works - and sometimes man-hours, if you're sober with requirements - you could win with the other approach. If you're adding something external, just make sure you're serious about that - documentation, technology background vetting, training, all those things. Otherwise the opinion that "external solution produced by team bigger than ours" is better could be based on an illusion.