Have been on board with this idea for some time, but, that said, here&#x27;s some criticism of the specifics:<p>&gt; Is there existing software that could be used instead?<p>Agree, up to a point. Very few OTS&#x2F;SAAS solutions are practical financially and customized, and if they are (as in a company that adds those crazy features you want to their SAAS app)- watch out! Those companies products will end up hitting a wall eventually because they will have coded themselves into a corner. Note: this actually because the company you are using didn&#x27;t use the 0.1x engineer philosophy.<p>&gt; Let’s not build&#x2F;deploy that development tool.<p>Maybe. But it depends. How often is human error affecting your process in a very time-consuming way? You wouldn&#x27;t say CI is a bad thing would you? What about using an IDE when you&#x27;ve got developers or a development language that best lends itself to an IDE? You would buy that IDE right (unless you&#x27;re really, really cash-strapped- compare it to the cost of a few days of your developer&#x27;s time)?<p>&gt; Let’s not adopt this new technology.<p>Maybe. How about instead- let&#x27;s adopt what are solid winners technology-wise that will help us attract new talent <i>and</i> develop features more quickly. And when we do that, we first do in small pieces that are independent to prove it out, then eventually we commit to using it as much as it makes sense so that we don&#x27;t end up with 3 tech stacks to maintain in ten years.<p>&gt; Can we achieve the same thing with a technology that the team is already using and familiar with? “The best tool for the job” is a very dangerous phrase.<p>Sure, mostly. But don&#x27;t get a shitty open-source IDE instead of paying $600 for a good one, or force developers that use UI tools to use vim because you&#x27;re too darn cheap either, even if it would do the job. On the other hand, I agree- don&#x27;t just buy things. Really let your dev teams hash it out and choose appropriate tools- don&#x27;t dictate anything without getting feedback and adequate buy-in when it comes to tools.<p>&gt; Let’s not automate this.<p>Again- what about CI and scripts that can help make developers work consistently, more productively, more efficiently overall, and with fewer errors?<p>Sure- if you are a one-man team, you might not need continuous deployment yet, but please don&#x27;t sit there and have devs pulling oars in your wooden sea vessel as the hovercrafts speed past you in the race.