Software - Build Vs. Buy

I recently had a discussion on the age-old debate between buying or building software. After giving it some thought, I came up with these ideas. Both options have their obvious pros and cons, and the best decision for each business will depend on its specific needs. However, a few principles stood out to me that I want to share.

Thoughts on Buying Software?

Buying software is quick and easy. You just buy it and start using it right away. There's no need to go through a lengthy development process or worry about ongoing maintenance costs. The moment you purchase software, you have instant access to all of its features and can immediately leverage its benefits. Whether it's an office suite, creative tools, security programs, or any other type of application, buying pre-made software eliminates the headaches associated with building it from scratch.?

The purchase of software can be costly, and you may not receive exactly what you require. In the previous paragraph, we discussed mainly tools. This is where the main distinction between buying and building is important. If what you are looking for is a tool and not the core of your business, then buying is the best option. Many services are typical from business to business. Payroll, accounting, CRM, and other similar tools and services are excellent examples of things you can buy. When you are looking for a product that is core to your business or will give you an edge over competitors, existing software may not be tailored to your specific business needs, and you may be limited in your ability to customize it.

Enterprise software-as-a-service vendors often include numerous features in their platforms, resulting in a broad "one-size-fits-all" offering. However, the Pareto principle suggests most users only utilize approximately 20% of available capabilities. Moreover, the subset of features used may not fully align with an organization's unique business needs and desired workflows. When a company requires specialized functionality to support its value proposition and competitive differentiation, the out-of-the-box solution may prove insufficiently customizable. This creates a dilemma between configuration of existing parameters versus extensive customization of the product. The former allows adjustments, while the latter enables building novel solutions within the vendor's ecosystem. For instance, Salesforce offers Force.com to empower customers to create customized tools natively integrated with its platform. It’s hard to balance comprehensive core functionality with the flexibility to address specialized use cases through customization and broad customization of a product can lead to even greater risks.

Customizing off-the-shelf software indeed presents the worst of both worlds. On the one hand, it incurs the high costs and risks of building software, which I will discuss below. On the other hand, it does not provide a fully customized tool for your business, and you remain confined within a specific ecosystem. Furthermore, as your business grows and the tool you are using continues to develop, you may not be able to access its latest features since you have customized the application and cannot upgrade your instance. Finally, many products offer APIs that make it easy to migrate to another product, allowing you to negotiate and have a credible path away. However, once you have customized a tool, it becomes almost impossible to migrate to a different product. In short, if you use a SaaS tool, you should obviously configure it to your business needs, but try to avoid customizing and building features specific to your instance.

Thoughts on Building Software

Building software is more time-consuming and expensive than using a third-party platform, but it gives you more control over the final product. You can create software that is tailored to your specific needs and requirements. A strong platform can completely change the trajectory of your company. There are many tools that allow assigning trips to drivers, such as OnFleet and Bringg. However, it is unlikely that Uber would have achieved the same level of success if it had used a generic trips assignment platform. Uber's success is due in part to its proprietary technology, which allows it to provide a more efficient and user-friendly experience than its competitors.

However, building software is not only more expensive but also entails significant risk factors. Deciding to invest in building a custom platform for your business does not guarantee that the software delivered will deliver the value perceived, just as paying your dues for the gym does not guarantee weight loss. You have to be persistent and you have to do it the right way. That said, there is a difference between risks and detractors of building software. Risks can be mitigated, whereas detractors are absolute negatives.

Risks of building software

Cash flow is a major consideration when deciding whether to build or buy software. Unlike SaaS, where costs are incurred monthly and grow in line with business activity, building software requires a significant upfront investment. This can be a major barrier for businesses that do not have the cash available to invest. In addition, the time it takes to build software can be lengthy, and there is no guarantee that the investment will be successful. Over a period of 5 years, assuming successful growth, the cost of building and buying software may eventually balance out. However, many businesses do not have the luxury of waiting that long to see a return on their investment. As a result, buying software may be the more attractive option for businesses that need a solution quickly and do not have the capital available to invest in building their own software.

Software development is a complex and challenging endeavor. It requires more than just coding skills. Good engineers can be measured and hired, but building good software also requires expertise in user experience, product management, quality management, and many other fields. It requires an engineering team that understands the subject matter they are working on. It requires strong collaboration between the technology organization and the business. Finally, it requires very clear objectives that will allow the business to clearly quantify the value of the investment and avoid vanity metrics and flashy features that are "cool" rather than valuable.

Software maintenance is an ongoing process that begins as soon as software is developed and deployed. It involves fixing bugs, updating security patches, and making changes to meet the needs of users and the business. Software is never perfect the first time it is deployed. As the business evolves, so does the software that fuels it.? External APIs also change constantly. This means that software that relies on these APIs must be updated to ensure that it continues to work properly. Even if no new features are being built, software maintenance is still necessary simply to scale.

Cons of building

Software development is a time-consuming process. Often, by the time features are ready for production, business needs have changed significantly, creating a long cycle of new feature development, more time, and so on. If certain features are needed immediately to win deals and grow business, it may be easier to purchase software that meets the current needs of the business. There is no magic way to avoid the time required to build software, but an agile approach can help deliver value in increments, rather than waiting for a long time and increasing risk. Beyond the expense, the opportunity cost and loss of confidence can be devastating, leading company leadership to scrap projects.

So when should you buy software and when should you build it? The answer depends on your specific needs.?

Here are some factors to consider when making your decision:

• Is this a core competency of your business
• Are you truly doing things differently
• What happens if you don’t have specific features
• How experienced is your team in building and scaling software
• What is your time frame
• What is your cash position

While I have not directly answered the question, I hope that the information in this document has provided some food for thought. If you are still unsure of which way to proceed, I would be happy to discuss the matter further and offer some ideas on how to mitigate risks and compare options.