Build vs Buy

In this article we explore the true costs of building software in-house versus purchasing a proprietary solution:

Limited functionality set

The cost of the in-house build will generally only include the initial cost for what might be called a ‘minimum viable product’ (“MVP”), a software package that meets the functionality set requested by the firm’s business users based on today’s business needs. While the MVP is costed on a ‘once and done’ basis, the reality with software is that it requires constant maintenance as business requirements change, the regulatory landscape changes and technology itself changes. A suitably qualified and experienced team of developers and support staff is needed to not only make all these changes but also to comprehensively test them.

Automated testing

Most in-house built systems do not have a comprehensive automated test framework for the software because building this will at least double the cost and the timeframe for the project. The time taken to manually test a new system often exceeds the time it would have taken to build the automated testing framework. Further, every time a change is made another massive manual test effort is required. This cost of building a comprehensive automated test framework or the alternative cost of large continuous manual test projects is seldom included in cost benefit analysis.

Security considerations

Financial services businesses, subject to high levels of regulation, will insist on minimum security standards for any proprietary software they buy. Security standards include access controls, vulnerability and penetration testing and oversight. Most in-house built applications will not have the same industrial level of security that proprietary software needs to compete in the market and the cost of building these security features is either not included or significantly underestimated.

Usability

In-house built software generally does not have the same level of usability and automation as proprietary software built to meet a market need. Modern proprietary software will be automated and exception based. On in-house built systems the task of running and validation a process is generally more manually intensive. Hidden costs associated with this lack of usability include higher staff costs and increased operational risk.

Auditability

Most modern proprietary software solutions include a full audit trail of all activity on the system, such as who logged onto the system and what processes they ran, and includes similar records for system initiated tasks. This comprehensive audit trail is generally not included as a requirement of an in-house built system and hence not included costed.

Scalability

Most in-house built systems are not architected with scalability in mind and are generally written to cope with current business volumes. If business volumes increase significantly it may be necessary to re-architect the system. Conversely, proprietary systems are built with scale in mind as the vendor will generally have a range of clients where scalability is a key requirement.

Upgradeability

In-house built systems will use the latest technology when they are built. Technology has a limited support lifetime of between 5-10 years, so unless the technology underpinning the in-house built system is continually upgraded over time the once ‘state of the art system’ will become an unsupported legacy system with significant ‘technical debt’. The interest on this technical debt will be paid annually, e.g. trying to obtain security patches for unsupported operating systems etc., but eventually the capital of the debt will have to be repaid either in the form of a re-write of the system or the purchase of a proprietary system. This McKinsey article has a good discussion on ‘tech debt.’ The upgrade cost (or the increase in the technical debt associated with not upgrading) is generally overlooked in the ‘once and done’ approach to costing the MVP.

Resilience

Regulators are increasingly focusing on the resilience of the systems used by financial services firms following some large-scale failures of IT systems in recent years. A recurring problem with in-house built software is that the developers move on leaving a knowledge gap. The level of documentation created for in-house built software is never to the same standard as that of proprietary software firms because internal staff will always have ‘higher priorities’ and the cost of keeping a development team capable of maintaining the in-house system to mitigate risk is seldom considered.

Cost Summary

The cost of adding these features is a multiple of the order of 3-5 times of the cost of the MVP functionality. Internal IT development teams may argue that such features are a luxury for an internal build and are not required at the outset but no procurement department would exclude these requirements in an RFP for any proprietary system.

In summary, the decision to build in-house or invest in propriety software deserves careful consideration. Two particular areas to consider in any comparison are whether cost comparisons are on a ‘like for like’ basis and the significant underlying economic advantage a proprietary vendor has in its ability to spread costs across its client base.

This is an extract from FRS’ latest whitepaper: Build vs. Buy - Key considerations for life assurance, pensions firms and wealth managers in deciding to purchase software or build in-house.

Download the whitepaper here