I’m not a huge fan of this because it’s kind of painting all “original (technical) problems” with a broad brush, while also being a rewording of the typical YAG

I’m not a huge fan of this because it’s kind of painting all “original (technical) problems” with a broad brush, while also being a rewording of the typical YAGNI/establish PMF advice lines. I suspect the author is coming from the perspective of primarily working on “applications software” like consumer sites or solving some novel/poorly addressed business need with software. A lot of these things aren’t binary yes/no decisions. They range from “don’t even do the thing at all” to “develop a custom solution completely in house”, sure, but with a huge spectrum of choices in between: buy off the shelf, get something basic but inflexible working, get something more advanced and flexible with more setup working, establish a process-to-be-automated that engineers perform manually. Especially on the <easy setup, kinda shitty> to <hard setup, powerful/flexible> gradient you really need to consider your needs and options’ risk/reward. Some things like tests and CI have such quick payoff times you almost always want something that does a decent job of things. Moreover, when selling technical products half the time your competitive advantage is actually being able to efficiently iterate and improve on the product faster than everybody else because competitors are bogged down in tech debt and manual operations.