For alternative fund managers, the classic decision of buy vs build is more than just a technology question - it’s a strategic one.

The simple heuristic often used is this:

Buy commodities. Build for competitive advantage.

But in reality, this decision has become significantly more complex, for three key reasons

1. Poor experiences with off-the-shelf products
2. Frustrations with custom-built solutions
3. Internal dynamics - from stakeholder preferences to capability gaps to budget pressures

There are four myths we should talk about in the build v buy decision:

1.    Time: A product is more efficient and effective 

With today’s advancement in technology, there is a real risk that multi-year technology implementations are superseded by new technologies even before it is fully implemented. This applies to buy or build.

Buying ‘off the shelf’ is more efficient and effective if it really does the job that you require. But here are the common pitfalls: 

• Many executives look to what their peers are doing as the benchmark or what is ‘market’- as the saying used to go, no one gets fired for using IBM. With the pace of AI, the ability to rebuild an existing technology solution at a lower cost is unprecedented. Will your vendor keep up?
• We often get seduced by a fantastic demo, but the reality falls short when applied to our business. 
• Much of the ‘off the shelf’ products require significant work to put the right data in to make the technology effective, which are hidden costs to an ‘off the shelf’ product. 

To increase the odds of both buy v build technology projects succeeding, consider a phased pilot which will give you a chance to test out your technology, technology partner or internal team.

2.    Stakeholders management: critical to both build and buy 

Managing stakeholders is a key requirement in the selection and implementation of a system, whether this is build or buy.

The management of stakeholders are critical in the selection process and many large organisations will opt for the use of RFPs in managing stakeholders and demonstrating governance. However, as many have experience, an RFP does not guarantee that the result is effective. 

During implementation, having a defined scope from a cross functional team who can clearly articulate a small set of requirements to go live, is important. Much like living in a house before doing major renovations, stakeholders will have a ‘wish list’ which can derail all projects. 

3.    Budgets: a bigger budget would solve our problem! 

Even if I have an unlimited budget, results are not guaranteed. There are a number of reasons for this. 

Many industry-leading technologies may not be as configurable as you think or may be set up for a different part of the market - the classic example would be geographical nuances that most systems are unable to readily cater for and this could be operational requirements (like accounting or tax) or market calculations (interest rates are calculated inclusive of days in some markets but exclusive in other markets). Having clear requirements, and clear objectives remain critical.

In addition to this, has the cost of maintaining multiple systems in the medium term, fully costed or considered? The cost begins from the selection process, through to ongoing due diligence, their maintenance of infrastructure, complexity of multiple systems’ data and technology footprint and cyber security.

The other costs which are not apparent are the internal and external touch points with each service that you sign up to from a more relationship perspective. A strong relationship is critical to get your requirements on the roadmap. 

4.    Expertise - for implementation and ongoing

Resourcing for the implementation and beyond is critical. Where you do not have access to expertise, the simple default is often to ‘do nothing’.  

For both build or buy, having the right advice: either internal or external, becomes a key part in the selection. Do you have, on your side, someone who has solved a similar problem before? 

It is difficult to work out whether the technology advice you are getting is appropriate for your business. This is often the reason to go to a product as their proposition is clear and there is someone who can maintain this product. 

With the pace of technology accelerating, there is a third option, choosing a technology partner. In the Australian market, firms have started outsourcing their technology to a partner in order to keep up with the market. The right technology partner can apply the appropriate technology for your business and will invest in attracting and retaining talent.

Conclusion: The Yin and Yang: It’s a spectrum, not a switch

The truth? No ‘off-the-shelf’ product is truly out-of-the-box. Every implementation needs configuration.
And no ‘custom build’ happens without off-the-shelf components (e.g., databases, cloud providers, APIs).

This is a spectrum decision. Not a binary one.

The reality is much more nuanced. 

Recommendation 

Having delivered over US$39 million worth of technology projects for asset owners and managers in private markets in the last 9 years, here’s what we have learned:

• Buy when a proven, market-leading solution aligns clearly with your goals (e.g., CRM or deal room platforms).
• Have the right technology foundation in place - consider the role of a modern data warehouse. 
• Build or partner when:
  • The solution needs to evolve with your strategy.
  • Data complexity is high.
  • AI can unlock new efficiencies.
  • Internal buy-in is mixed and trust in vendors is low.

In every case, make sure:

1. A capable technologist is in the room for the decision.
2. Broader data architecture is considered to avoid spaghetti systems.
3. You’re aligned on 1-2 key objectives (with non-negotiables).
4. The person leading the project has solved this similar problem before.
5. Take a longer-term view and focus on what gives you a sustainable edge.