Software development is all about picking the right tools for the job. The right tool is a function of problem complexity, team size, experience of the team, ma

Software development is all about picking the right tools for the job. The right tool is a function of problem complexity, team size, experience of the team, maintainability, and other factors. There are two main types of tool selection failures I see: 1. Teams that try to choose the “best” tools according to what they perceive as the state of the art without regard to the problem their trying to solve. This tends to become a game of picking whatever they think FAANG might be using, even if their problem is orders of magnitude smaller and simpler. At the extremes, these are the teams that end up building a Kubernetes-deployed custom React-based CMS with server-side rendering when really they could have set up a Wordpress install with a custom theme in a couple of weeks. 2. Teams that embody the phrase “When all you have is a hammer, everything looks like a nail.” These teams have been using the same tech stack for a long time and they’re so good at it that they refuse to consider anything else. Instead of trying new tools, they try to brute-force their current stack to get the job done. Some times this works well if the problem is a good fit for the stack. Other times, they waste a ton of time and money doing things that could have been solved quickly by trying a new tool. None of us are perfect, but most failures fall into one of the two categories above. Eager startups often struggle with #1 when they have a pseudo-CTO cofounder who wants to pick all of the technologies but hire someone else to do all of the work. My approach is to draw up multiple proposals with different stacks and present them with an overview of possible risks, benefits, and timelines. Usually once it’s all laid out, reasonable engineers might recognize that the right tool for the job isn’t always the trendiest tool. It takes some good presentation skills to navigate this but it can be done. At the same time, I see some opportunities for you to grow your experience a bit. A CI/CD system has real benefits for delivery, but it shouldn’t require 3-4 full-time engineers to get going. It’s worth learning how to do this right so you can actually evaluate it, rather than dismissing it as useless complication. Frankly, setting up a basic CI/CD workflow with modern tools like GitHub or Gitlab isn’t a big chore. You should be able to come up with something usable and a good understanding of the basics in a workweek by yourself.