Odds are one of your company’s largest expenses comes from software licensing and/or development labor. While licensing fees can sometimes feel outrageous (at the enterprise level tilting well into the 6 and 7 figures per year), building custom software for your business is rarely the cheaper solution up front. Internally developed systems often come with unforeseen downstream costs that multiply as the system grows in complexity.
We need to consider why we use software before determining which path to take when deciding to buy or build a new technical solution. We may need to automate some repetitive tasks, reduce the occurrence of operating errors (i.e. bookkeeping), leverage existing employee workloads, allow for audit trails, or share real-time inventory data. The list can go on and on.
If you choose to build a new piece of software for your company, it must either provide improvements to the bottom line, lower long-term operating expenses, or both. These cost reductions can come in the form of labor efficiency (i.e. fewer manhours), reduced error rates (i.e. cleaner data) or reduced variable by way of decreased dependence on escalating SaaS fees.
If the business has interest to sell digital products, then internally created software can open up the potential for new revenue streams, offsetting the costs of development. The up-front costs to build software can be incredibly high. However, if these costs can be amortized, in combination with revenue improvements, you may have a compelling case to take on the challenge to build the software in-house.
However, building new software comes with a cost that cannot always be reconciled given a business’s financial situation. For example, a startup that cannot afford the labor or a business that has no domain expertise to manage a given project. Buying or licensing software is the right move in these situations.
In deciding when to build vs. buy we need to think about the relationship between costs, revenue and margin improvement of each decision. To get a better understanding of when to build or buy let’s explore four scenarios.
The API has commercial viability and our business has the expertise to manage product development. In this case, the new software can provide improvements to our top line revenue, so we need to evaluate the choice based on the operating leverage created by undertaking the project. We can begin to harness operational leverage to create margin improvements as the business scales its output. By
Operating leverage measures fixed costs, such as salaries, against the variable costs of operating a given business (e.g. SaaS fees based on usage). The degree of operating leverage is calculated as the contribution margin divided by the total profit. In our example, reduced dependency on escalating SaaS fees (variable cost) allows for better leverage (i.e. margin expansion with increased business). The downside is that these fixed costs, in the form of engineering labor, are large and if the product fails to take off can weigh on the business’ bottom line.
When your business has the domain knowledge and the capital available to manage the added fixed costs of labor, a newly built piece of software that offers added revenue potential and operating leverage should usually be built in house.
Adding SSO for our enterprise customers will increase revenue. However, authentication/authorization systems are complex and time consuming to build. Failure to properly implement security software can lead to business disasters. With revenue expansion in our sites, we need to contemplate the potential costs of building in house.
Comparable security products available are incredibly expensive. Okta, for example, charges roughly $50k for 100,000 active users annually to manage SAML SSO. At first glance, this seems like a lot and the knee jerk reaction from management might be to build it yourself. But our company most likely lacks deep domain expertise in software security.
Of course, our engineering team can figure it out with enough time on Stack Overflow, but this type of project will take months. By taking this project in house we would have to shift the core focus of the team away from the real purpose of our business. Over a long enough timeline, the cost to build in house (mostly fixed and upfront) will be far less than licensing. However, mismanaged labor allocation can have dire consequences, especially if the products or services are not in the security and identity management space.
So long as external vendor costs are not completely prohibitive (i.e. unaffordable), it will almost always be better to focus engineering efforts on your business’ core product offerings. At a certain scale it may make sense to bring these high-ticket software components in house. For most, SMB or non-tech businesses this circumstance calls for buying the software.
A news organization managing articles and advertising displayed on their websites via a CMS is a perfect case study. While some out of the box solutions (e.g. WordPress) exist to manage simple text and multimedia content, any sophisticated content presentation or data presentation will warrant some type of custom solution.
For many businesses, the exact solution simply is not available for licensable purchase. There is no one-size-fits-all setup when it comes to managing a company’s data. As a result, we will need to build this solution. This process will get expensive and does require your company to invest in a long-term vision of how technology will enable top line revenue growth. With well-built CMS software, your firm can reduce errors in data, increase speed to release and improve the core product offerings by bringing a unique flavors of data visualization and content presentation.
The only question in this scenario is whether to build in house or utilize an external agency. In my opinion, over reliance on outside sourcing firm leads to cascadingly poor business decisions. The goal over the long run should be to bring maintenance and management of any core software system like a CMS in house.
Unless you are Intuit or FreshBooks, odds are your project managers do not know the nuances of accounting rules. While your CFO might be able to help, odds are its not in the best interest of the business to have your finance team managing a software development project. Additionally, the cost for high quality accounting software is incredibly low and provides an extreme amount of value to the business in the form of bookkeeping error reduction, invoice automation and cash management. By purchasing you avoid massive fixed costs you would incur by building (e.g. engineering salaries) with minimal increases to variable costs (e.g. software usage fees). A cheap piece of software in a complex domain outside your business’ scope is a clear candidate for purchase.
Without the prospect of new business growth, a company outside of tech is generally advised to avoid managing their own software. It distracts your team and may not provide sufficient return on invested capital to warrant either development or purchase. Kelsey Hightower, a well-respected Google Cloud evangelist, has one of the poignant and hilarious open source projects that address the suggested aversion to building more software: https://github.com/kelseyhightower/nocode .
At the end of the day, until you can forecast tangible business benefit avoid writing code. The tipping point in deciding to build your own software comes when money is at stake or there is simply no other option. If your company makes the decision to move forward with a given engineering project, just promise me you won’t be like Boeing .
Below are a handful of questions to consider when faced with the decision to purchase, build, or maintain your company’s manual processes:
- Is the problem being solved specific to your business?
- Is there software out there that can be purchased and covers 95% of use cases for your business?
- How difficult is the integration of the software to your internal processes?
- Will buying the software reduce headcount or hiring pressure?
- Do you have the talent in-house to develop such a system?
- Would other business units also benefit from in-house engineering talent?
- If you choose to buy, how hard will it be to unwind this decision in order to switch providers or build the system in-house?
- If you choose to build, how often will it need to be updated?
- How do long term updates and maintenance impact the timelines of other higher leverage projects?