Build vs. Buy – That’s the question

5 min readJan 3, 2022

Is buying standard software off the shelf more efficient compared to building the solution from scratch?

For a long time, the general opinion has been ‘if it’s standardized, you are better off buying than building’.

Thinking about all the overhead software brings, the statement seems legitimate: Authentication, Logging, Routing, Error handling, Load balancing etc. are just a few of the topics to mention, which are for most part invisible to the final user, but are basic and mandatory requirements for working software. Your developers would be spending more time developing that, then working on those lines of code which actually make the business happy.

The downside of standard software, though, are rigid and inflexible systems, which do not 100% match with the business needs. What usually happens are customization on top of the standard software or complex configurations, as well as…well: the business adapts it’s processes so that they fit to the software. In the finance area e.g. this usually means: input data to the software via excel. Receive results from software via excel. Those resulting files are called ‘Database’ and are the backbone of financial statements and management reports. Scary.

The real bang for the buck, software and digitalization delivers, comes with integration. Seamless, automated and perfectly integrated processes, in which the software takes all the heavy lifting, adapts to the underlying business process, and the business user simply gets the required results. Utopia?

With Custom build software definitely not. However, is it worth spending the extra time and money building everything from scratch or rather let the CFO have the one or other excel sheet left in his or her closing processes?

To answer this question, we have to review the initial statement on make vs. buy. This statement might have been true for the past decades. However, with the rapid improvement of software tools & technologies, the advent of open source as well as cloud computing, the decision on make or buy is not so clear anymore.

Build vs. Buy in Action

Same decision I had to take when we had to find a solution for our finance department and their IFRS16 reporting. The current process was purely based on home-made excel files, which are not standardized throughout the group. With 44+ companies and average 10 active leasing contracts per company it started to get very painful just managing the reporting. Not included the management of the contracts itself.

After having reviewed the offer of some very well known providers of IFRS16 solutions, their resulting capabilities and knowing the system landscape as well as the reporting requirements of the group, for me the decision to build the solution from scratch was crystal clear.

This decision was taken end of September 2021. Implementation started beginning of October 2021. Friday, 10th December 2021, we received the final confirmation from our business partners, that the remaining set of test cases did pass. The solution is internally approved and I am looking forward to meet the auditors in Q1 2022 to get also the green light from their side.

The implemented solution consists of a web application for the management of the contracts (incl. wizard functionalities, flexible payment plan calculations & notification services), which is integrated to the groups data warehouse and standard reporting. Apart from the DWH & reporting, which follow a modern lake house architecture in Azure, the solution is purely build with open source technology: Node.js & Vue for server-side & client interaction, Python for complex financial calculations required in IFRS, and MongoDB as database underneath the stack.

With total of 2 FTE from the Digital Office and 0.5 FTE from the business involved over the course of the project, the implementation cost are around 0.5x of the best offer from vendors. Not considering any customization & implementation efforts and the potential lack of integration.

Factors for quick and successful implementation

I would love to claim that the success is a result from us being super clever :) I have to admit that we have some bright minds among our staff. However the critical success factor was the rigid adherence to classic digital transformation and agile software development guidelines:

1) Set up of committed, empowered & cross-functional development team

Main factor for the successful implementation was the way how the team was structured. With only 4 different people (1 FE Dev, 0.5 Data Analyst, 0.5 Backend Dev, 0.5 Business Analyst) the Team was very small but equipped with all necessary knowledge. Having the CEO as a sponsor behind the project, the team was fully empowered to take decisions, impediments could be resolved quick and efficient.

2) Rapid prototyping and extreme programming

In the beginning of the project, biggest concern among our business partners was the handling of complex financial calculations. In order to mitigate those concerns quickly, we used rapid prototyping. Within two days, a basic user interface build in PowerApps was implemented. This gave back the confidence, as there was early in the process something tangible to see as well as the calculated results already matched basic contract structures. In addition to that, this basic user interface already incorporated some nice wizard functionalities which have not been available in the excel sheets before. This created excitement among the team and increased engagement.

In addition to that, we applied certain forms of extreme programming into the process: pair programming of front- and back-end devs to reduce feedback loops and improve code quality, joint dev sessions with the business analyst to rapidly code and test requirements on the spot. We also used bootstrapped components of the user interface to match other internal applications for look and feel increasing adaptation and reducing custom built components.

3) Quick and regular feedback — Continuous integration — Continuous deployment

To be fast and to quickly respond to user feedback, we ensured split of environments as well as introduced multiple daily deployment of code updates. We didn’t follow classical sprint cycles but rather deployed every contained features individually. This was a huge value driver, as bugs or issues in the calculations will stall the testing from business point of view. For them, there is no point of testing a system with faulty values as all results are interconnected and would require to redo the testing anyway. Calculation bugs where addressed first and fixes deployed multiple times daily.

This requires a light-weight and flexible architecture. Our merge and build processes never took longer than a few minutes. Rigid adherence to quick test and feedback loops reduced amount of change deployed to the different environments, testing was reduced to small and manageable test cases. This could be achieved by having a committed team as mentioned in 1). We did not yet have an automated CI/CD pipeline in the development phase, yet. This is planned for upcoming cycles.

Summary

There is no clear cut decision for build vs. buy in software development. Buy-decision should be made if the required solution is complex, standardized and results in well-integrated business processes. Build-decisions, though, are in favor if the available solutions do not well integrate into required processes or do not provide core business-required functionality. If you go for ‘Build’, following of agile software development principles is a critical success factor for business value, happy devs and even more happy business partners and customers.

#softwaredevelopment #makeorbuy #agility #digitaltransformation