Build vs Buy
What is the right option for your company?
Choosing between building your own business tools software in-house or buying in ready-made versions can be a multi-faceted decision but here are some guiding thoughts for consideration.
If you are a business training and performance company without an in-house IT team, or if your IT team are lacking in business tools software building knowledge or too busy, then buying in is the obvious answer. Given the expansion of the technology and software industries, there is no shortage of available products from which to choose. On the other hand, many companies have invested in their own IT teams who able to customize and integrate. Shared knowledge is also increasing and software vendors and in-house IT teams are working to similar design and implementation standards and development best practice. Where in-house IT teams are lacking the knowledge to implement certain features in business tools software, then buying in is a safer option. It makes sense to buy generic products such as Microsoft Office 365 suite or MS SQL Server. Why build what already exists?
Core Competency vs. Plug-and-Play
Some companies might have software building as part of their core competencies and financial institutions would be an obvious example in this instance. The other end of the build spectrum is to buy generic products with multiple functions. For example, IT teams can buy licenses to Visual Studio, business departments can buy Salesforce and HR teams can use PeopleSoft. These types of generic products are easy to install and have been widely trialled. If the software falls into one of the ‘core competency’ vs. ‘plug-and-play’ options, then the build vs buy question answers itself.
Need for Speed
The majority of ready-made, business software has a guaranteed delivery time. However, you might need to consider the lead time for the procurement process, customization and integration time together with any process adjustment and training time. Whilst the buy approach has some advantages at the time of delivery, you might consider the build approach if a multi-stage development cycle is possible. An in-house IT team could, say, deliver a set of business tools and associated features to meet the timeline and quality requirements and then add features in later phases.
Companies striving to maximise the ROI might lean towards the buy approach for advantages in pricing. Ready-made products have wide user, lower unit costs and scalable deals. Many vendors offer the subscription pricing model which negates big upfront expense. Modular structured products mean customers can pay for what they really need. Buy supporters usually do well when comparing the costs of the software to equivalent in-house software. However, some companies might not actually use all features of a buy option. There’s a false economy in buying what you don’t use. When estimating the total cost of bought-in software, it’s easy to miss out the cost of researching, of customization implementation and of integration with existing infrastructures. Costing comparisons should be finely made and specific to each vendor and product. There are bargains to be had with widely used software or services but more specialized products need careful inspection in relation to costs.
Most applications need customization or integration with existing infrastructure or other systems. How will the solution map into the wider business processes? If there are gaps between the bought-in product and the current business processes, could the in-house IT team work on customization? Will the solution integrate with existing systems and technology? Some companies are open to non-compatible solutions but others are not. Even though the build product can integrate well, more and more solutions are now designed to designed to be agnostic. Does the solution complicate the overall architecture? Does the solution meet all security requirements and legal compliances? Will it be scalable, reliable and easily available?
Maintenance and Support
We all hope software runs seamlessly forever but things always change. Both the buy and build software will need to install updated versions to include security patches, fix bugs, and/or add new features. People usually think the service level of in-house IT teams is better than that of vendors. For a built application, the in-house IT team has more control over the solution, thus better maintenance and support quality. If a company opts to buy a product, it may find a vendor takes longer and charges more for maintenance and support. A better way is to have a service-level agreement (SLA) signed when acquiring a product or before building an in-house application. The SLA permits all parties to understand their responsibilities involved with the use and maintenance of the software.
The build vs. buy debate is challenging. There are pros and cons on both sides, and there is no easy formula to compare the two approaches. Analysing delivery time and total costs helps ensure diligent software procurement or development. Examining non-functional requirements guarantees smooth software installation. A careful study of the maintenance and support assures the sustainability of the software. The build vs buy choice is more of an art than science. Nothing is an absolute. The good thing is, build and buy are competing with each other and both are improving.