Home > Content Automation > Build or Buy: How to Decide?

Build or Buy: How to Decide?

When looking at content automation and sales enablement solutions, firms are often confronted with a tough decision: To build or buy? Over the past 20 years, I’ve participated in many of these discussions and seen it go both ways. Sometimes the decision is successful and other times it ends up a costly mistake. On one hand, it isn’t always less expensive nor less risky to build software as opposed to buying commercial solutions. For example, when application development projects are initiated with the intent of justifying and maintaining the technology team. Then, unfortunately, they never get off the ground because they can’t be supported technically or economically. What then happens, after all the internal effort and expense, is a new commercial solution is procured to replace it.

On the other hand, sometimes the technological or business needs are so pertinent to operations that they cannot be outsourced. In these circumstances, there’s a good case for insourcing as opposed to outsourcing if the board of directors approves. Also, the IT organization must be truly committed to the budget and vision. At the end of the day, the success or failure of development efforts should be measured against the same criteria. When weighing the decision to build or buy, I recommend using these six criteria:

#1 – Timeline & Budget

First, it’s important to take into account the timeline and budget predictions for each approach. Will the project be completed in a timely manner and close to budget predictions? In my experience, internal project costs usually aren’t very tightly tracked or cost controlled. It’s easy for production costs to be absorbed into the salaries of employees working on the project. Before building an internal solution, firms must have controls in place to track and measure production costs and efficiencies, sustainability of the product, and ROI on resources spent. The same controls must be in place from a vendor solution before making an investment. More often than not, firms have more recourse and cost controls using a vendor solution.

#2 – Functionality

It’s important to analyze the functionality of each solution to determine if they can satisfy the business requirements. When looking to build internally, there should be incentives for an internal solution to go beyond minimum requirements. The business acts as a single client setting the specs for a one-off solution. So, a firm must make sure the results will go beyond minimum functionality and perform at or above commercial standards. If the internal IT department has the resources, commitment and support to create and maintain a solution, risks are minimized significantly. Vendors are incentivized to make their product technology competitive in the marketplace, thus they’re inclined to have proper functionality. Be sure to vet commercial technology solutions against their longevity, client references, and competing products. Then, you will understand how they measure up to other solutions and what risks are involved before investing.

#3 – Testing

A successful solution will be well-tested and bug-free. Will the development teams be responsive to bugs and issues encountered by users prior to and during deployment? The discipline of software testing, particularly if significant user interfaces are involved, is challenging in even the best scenarios. When doing this for an internal solution, make sure the team is prepared for all facets of software testing. Commercial tools should all have a formal testing function. They have a larger use-case library and more established development and testing teams. Check references and performance standards before deciding on any vendor solution.

#4 – User Documentation

The technology needs to be delivered complete with appropriate end-user documentation and training. A technology solution’s functionality has to be repeatable for future users, or it is not sustainable. Development of documentation and training material must be a forefront thought for internal projects. The IT team is using the solution. Therefore, they will be responsible for making sure documentation doesn’t take a backseat to other initiatives. Once documentation has been accomplished, it will need to be vetted through repeated use and enhancement. Commercial products and reputable vendors typically have a well-developed documentation discipline. Vendors are expected to have proper documentation to provide clients. So, firms should ask to see and review it before the vendor is chosen.

#5 – System Documentation

Before choosing a solution, internal or outsourced, make sure the system architecture is well-documented. This will ensure that if people involved “move on” it can be supported by new resources. In my experience, well-produced and thorough technical system documentation is possible, but rare with internally developed solutions. Make sure it is not treated as an afterthought and is not sacrificed to help contain budgets. When an internal team has truly committed to creating a sustainable product, they will create system documentation as they go. Most vendor solutions are created on the assumption that there will be a version 2.0 and version 3.0. The vendor will be put out of business by employee turnover if they do not capture architectural knowledge in writing. The incentives are to be thorough and consistent in technical documentation.

#6 – Maintenance

In a supportable technology solution, the system has to be budgeted and staffed for ongoing maintenance, support, and upgrades. It’s crucial for the team responsible to have the skills and resources to execute them. The development goal of an application solution is for it to operate like a line-of-business operational crown jewel. The budget and skill set required for quality ongoing maintenance, upgrades and support must be well maintained. Support, maintenance, and upgrades should all be business-critical activities for a commercialized technology solution. Without investing consistently in these areas, a vendor will not have good references or longevity in a marketplace.

Conclusion

Whether you decide to build or buy, the final solution should be designed around four hallmarks of success. These are repeatability, sustainability, market competitiveness, and profitability. Taking an honest, thorough assessment of the internal build vs. vendor solution is critical for success, and for your career. Next time you’re faced with a decision to build or buy, use the six criteria above to compare the solutions. For a more detailed look at how to make a case for building or buying a technology solution, download our whitepaper, Should Your Financial Services Firm Build or Buy Automation Technology?.

Here are some related resources that might interest you:

John Toepfer

John Toepfer is CEO and Co-founder of Synthesis Technology. He is a technology entrepreneur, investor and business owner with a 25-year background in building and supporting communication solutions for the financial services industry. He lives in Chicago with his wife and two sons.

January 14, 2019

John Toepfer