The most valuable conversations I have with product leaders are the ones where I fire myself. Sometimes the best solution is not writing more code.
Writing code comes with tradeoffs worth considering before starting a new initiative. All code, even perfect code, requires maintenance. Maintenance includes more than repairs when needed. It also includes hosting the code and reacting to change in others.
Once the code is written, it has to live and run somewhere. Typically, the source will live on a version control platform like Github, and either run on local desktops, on a dedicated server, or a cloud service such as AWS.
If the code interacts with any other piece of software, which almost all software does, you have an increased surface area of risk. Let’s say you integrate your internal software with your email service. What if that service changes their API, or their servers go down, or they go out of business? What if your company decides to switch services? In all of these cases, you’ll incur a maintenance cost.
If debugging is the process of removing software bugs, then programming must be the process of putting them in. --Edsger W. Dijkstra
If this new code is a new feature that your clients use, then there is also an inherent customer support cost as well. This goes both with answering questions, but all the “give a mouse a cookie” effect new features can take on. If you can integrate with one email service, why not all of them?
All this is not to say you should never write code. Instead, you should consider that new development is one tactic in your arsenal out of many. What are some others? Instead, consider using off-the-shelf services. For example, building your own marketing automation solution on top of AWS SES vs. using an off-the-shelf solution like ConvertKit. Then, you can compare the monthly or annual cost of a service with the maintenance and development cost of building it yourself.
Do you have any examples of when you were asked to build a custom solution, but found a different alternative?