Businesses of all sizes are often faced with many foundational decisions in their infancy. To build or buy? To build in-house or outsource? These decisions both have their pros and cons and in this blog, we will take a look at some of the strategies for approaching them effectively.
One of the initial questions that may come to mind is, “What problem are we trying to solve in the first place?” This ties back to an organization’s long- and short-term goals and is important to consider because it is the foundation of every build or buy decision. For example: the organization may want new software to gain a competitive edge, expand to a new marketbase, or combat an ongoing problem like declining retention rates or customer satisfaction. Take for instance: a company that (in one year) triples in size and can no longer support the overwhelming number of support tickets they are receiving on a daily basis. In this scenario, this company would need to solve this problem as fast as possible or risk losing credibility with its customers. On one hand–the company could build a ticket support system in-house, which would give them full autonomy over a custom-built solution tailor-made to their liking. On the other hand, they would have to ask themselves if it is worth it. Building in-house can take a lot of time, and unintentionally introduce more maintenance overhead in the long run. As an example, they may choose instead to purchase a ticketing support solution, thereby getting a quick resolution to their problem and keeping good communication with customers. On the flip side, picture a data analytics company spearheading a project that would require several integrations with various platforms and instead deciding it is simpler to build an in-house solution rather than researching, vetting, and purchasing something that ultimately may not have all of the integrations needed and stalls business productivity. In other words: the time and additional overhead might be worth it if it doesn’t hamper productivity.
The complexity of the potential solution and the competency of the organization to respond are also hugely important factors to consider in buy vs build deliberations, especially as it relates to the speed at which the system can be built. Are the right engineers in place on the team and do they have the knowledge and experience to get the job done? Do they work well together? If not, how long would it take to hire and build out a dream team? If there is a “technical deficit” within the company (that is to say where there is a lack of talent and finances available to see a project through to the end) it may be better for the company to buy. It’s important to note however that companies will need to adopt a fluid mindset in their approach, and what once seemed like a solid buy situation can quickly pivot into a build situation (especially if a company experiences unprecedented growth in a short period of time). A great example of competency tackling complexity showed itself in 2012 with the video streaming giant Netflix. Netflix utilizes a CDN (content delivery network), and in the early 2010s, during its infancy, Netflix used to outsource this job function. As time went on however and Netflix’s traffic and volume grew, third-party providers were no longer up to scratch and the streaming tsar was forced to invest and build in their own CDN. A seemingly complex buy vs build problem was solved thanks to a competent staff and thus Netflix’s very own “Open Connect” CDN was born!
A strategic budget strategy is also vital. After reading that last section, you’re probably saying to yourself: “Most companies don’t even have the budget to build their own CDN no matter how much technical expertise they possess” and you would be absolutely correct. In fact of everything mentioned thus far perhaps the most important factor comes down to (not surprisingly) money. Most organizations don’t have a big enough budget for building enterprise-level software. Between salaries, marketing expenses, and equipment costs, allocating the funds to build a solution (no matter how needed it is) will be the last thing on leadership’s mind and they may opt for a third-party product and justify committing to a monthly payment or annual expense instead. You may be thinking: “Doesn’t opt to buy in this scenario as opposed to building leave you in the same predicament when it comes to your budget?” Well not necessarily. You see, when deciding whether or not to build a solution you also need to take into account the long-term technical debt associated with hosting and maintaining your solution in addition to the upfront costs. It’s similar to deciding whether to buy a home or continue to rent. If the decision comes down to the fact you don’t have enough money for a down payment (upfront costs), you will probably end up renting even if your monthly rental expense is equal to what you would pay for a mortgage (technical debt).
At this point, it’s useful to address that there are risks associated with these decisions primarily when it comes to buying. For starters, it is important to remember that when an organization elects to buy over building a solution they are surrendering their data when purchasing from a third party, and so taking into account privacy and regulatory concerns the most important question to discuss internally is: “how will this third party company use our proprietary/customer data?” If your data is critical to your company maintaining its competitive edge it is vital that it remains internal. Another thing to consider is the associated security risk and whether the third-party provider is following cybersecurity best practices. Large-scale cybersecurity attacks are a constant threat and it is important to make sure a third-party provider has been properly vetted and can be trusted.
Finally, sometimes it’s not a matter of buy vs build, but rather an incorporation of both. A Hybrid approach, where an organization purchases a solution to build on it to fit their unique needs, can often be the best approach because when executed efficiently it allows organizations to connect their in-house tools with off-the-shelf software. Perhaps the core benefit associated with the hybrid approach is that it offers organizations the opportunity to have peace of mind in that they can purchase a tried-and-tested product from a company with a dependable track record, and as a result, build upon proven technology. By incorporating this strategy, not only can solutions be tailored to fit specific needs but the hybrid approach also allows room for flexibility as a project continues to evolve.
Deciding whether to build or buy is never a straightforward or easy decision, and it is important to take all the pros and cons into consideration to avoid investing in an unfit solution. As we have seen, building while time-consuming allows for more customization and control while buying is a more rigid approach with added benefits like automatic updates and maintenance. The best recommendation for enterprise leaders is simple: do your research, assess your options, and always remember every organization is unique. It can be tempting to look at a competitor and think: “This strategy worked for them so surely it will work for us!” but the decision is never a “one size fits all” situation and just because one solution works for a competitor doesn’t mean that it is a solution that is fit for your company. That being said, it’s best for organizations to have proven experts who know the level of effort required for building or partnering with solutions. By taking into consideration long-term goals, the complexity of a potential solution, budgeting, and the risk associated, organizations will be better equipped to navigate the build vs buy dilemma.
