From start-ups to large Enterprise companies the debate of whether to ‘build’ or ‘buy’ software is one that comes up on a regular basis.
While we develop software for the Funds Industry at Fund Recs we also use many external tools to make us more efficient.
For example, we use OnePageCRM for sales, Microsoft Office 365 for business applications, Slack for team communication and Amazon Web Services for our application Cloud Infrastructure.
Each one of these were selected because of their close fit to our requirements and for their market leading features and functionality.
Collectively, across those 4 solutions alone, it’s not farfetched to estimate easily over 1 million hours of development time has been spent getting them to where they are today.
Of course, we don’t just get the benefit of the current solution but also all the future innovation that gets added to these products through R&D, competitive pressures and exposure to the market.
Most readers will agree that at Fund Recs sourcing these external tools is a much better decision than building our own CRM, Office suite, team chat and cloud infrastructure!
When it comes to Enterprise companies with Internal development teams, making decisions to buy instead of build can be a lot trickier with internal politics at play and a large group of interested parties to convince.
This isn’t a self-serving article disguised as a balanced review. There are many of those online already! Having worked on dozens of technology projects with both internal builds and external buys it’s my opinion that if your requirements aren’t a core competitive edge you should bring in external expertise.
For this post, I’m going to explore some of the key reasons that can tilt the decision in favour of buying at large Financial Services companies when examining the prospect of building vs buying a solution.
Technology in most Financial Services companies will often be an enabler rather than a core competitive advantage.
Excluding the likes of PageRank from Google (which is a core competitive edge) most company’s technologies are built around a combination of existing widgets and common underlying infrastructure.
It’s often client service, business models and brand that large Financial Services (FS) companies rely on to grow and compete.
Recently we’ve seen global banks such as Goldman Sachs and JP Morgan falling over themselves to be perceived as “technology companies”. While I welcome the acknowledgement of the importance technology plays in today’s successful companies I don’t think it’s healthy for a thoroughbred horse to consider itself an eagle and try to fly!
Most financial services companies spend over half of their budget maintaining and supporting existing applications. Most of this legacy infrastructure supports the ‘services’ part of FS rather than providing a standalone income as a technology platform.
A good rule of thumb when checking if a new solution does or does not provide a competitive edge is to ask whether it will directly lead to new revenue that couldn’t be achieved without it.
If the answer is no then the solution more likely provides a short-term efficiency that isn’t a long term competitive advantage.
This doesn’t under estimate the importance of these incremental gains because added together the process of constant incremental improvement can be very powerful. Once a company stops making such improvements they’ll quickly fall behind the pack.
Another thing to consider is that pulling internal resources onto this project has an opportunity cost that might be better spent pursuing projects with potential for creating a true competitive edge.
When companies decide to go down the internal development route there is normally a project manager appointed and stakeholders, objectives and timelines identified.
The product manager is responsible for setting the product strategy.
By having an objective focus to building the product, the best product managers can create initiatives to help reach those objectives mid project. This approach helps determine which features should be built to achieve those objectives. Product managers must answer the following questions:
A big challenge with internal projects is once you enter the development phase it can be very difficult to course correct based on feedback or new information.
A common scenario is that business requirements will be relayed to the development team early in the process. The development team then deliver these requirements as specified but since then the business unit realise the requirements have changed due to a new client onboarding and want to make alterations to the original design.
The development team push back and say they have delivered what was specified on time and any changes now will delay the project. A process of compromise now ensues with internal political capital spent by both sides to try to get the best outcome for their respective groups.
External vendors (the good ones!) will have a Product Manager leading development on each solution and she will have the power and influence to rally the team to respond to the new user requirements. She is responsible for achieving Product/Market fit with rebuilding features, adding resources and pushing back when needed all tools in her arsenal.
With Internal builds once the initial version is completed the project team can be disbanded or move on to the next shiny thing. Straight away the solution begins to become obsolete. Without external market pressures and an ongoing Product Manager the solution soon falls victim to ‘good enough’ until it isn’t.
In a period of post financial crisis and heavy regulation financial services firms across the global have been forced to focus on their balance sheet and reducing liabilities and increasing assets.
At every opportunity firms have been looking to move capital expenditure (CAPEX) to operational expenditure (OPEX) as they seek to appease both regulators and investors.
In parallel, the software world has seen a massive shift towards Software as a Service and cloud computing. This new ability to provide widespread solutions with a pay as you go model has allowed many financial services companies transition CAPEX to OPEX, thus improving their overall financial position and capital efficiency.
This is not possible with internal builds as the majority of costs are incurred up front and must be capitalised.
It can be difficult to accurately compare vendor to vendor pricing never mind external to internal.
The easiest way to do this is to calculate the ‘Total Cost of Ownership’ over a set period. This can encompass the life time of the solution or arbitrary periods are often used e.g. 3, 5 or 10 years. The key to this is to not leave anything out and try to include any ‘hidden’ costs.
Calculating these figures accurately can replace emotion with facts in the debate of whether it would be better vaule to build internally vs buying an external solution.
Below is a high-level checklist for items to include when evaluating total cost for both Internal and External:
For internal include:
For external include:
To help quickly compare an internal solution versus buying you can use our basic Build vs Buy calculator at the end of this post.
Build vs Buy is an important strategic decision and a misstep can often slow a company down for years to come.
Sometimes buying the wrong solution can be confused with making a mistake to go external, when in fact the external option was the right choice but executed poorly.
Key points on why I think an external solution is most often the best option can be boiled down to:
Have you got a success or failure story on a project that was developed internally or bought in from an external vendor?
Would love to hear your thoughts and/or stories on the build vs buy debate in the comments below.