Decoding the Dilemma: When to Build vs When to Buy

Ankur Mongia
Beyond Agile Leadership
3 min readAug 19, 2024
AI-Generated rendition of a team sitting and comparing Build vs Buy analysis generated using Copilot
AI-Generated rendition of a team sitting and comparing Build vs Buy analysis

This article shares my experiences in making Build vs. Buy decisions for software applications that support our customers. My perspective comes from a background deeply rooted in building applications from the ground up. I’ve always taken pride in creating homegrown solutions that cater specifically to our customers’ needs.

However, with the rise of cloud computing and the proliferation of SaaS (Software as a Service) platforms, my views have evolved over a period of time. I started to explore the out-of-the-box offerings that these platforms provide and assess their value compared to the knowledge that I have acquired on custom-built solutions.

While many resources are available on how to approach a Build vs. Buy decision, I won’t rehash those principles here. Instead, I’ll share what has worked for me in reaching these decisions:

1. Drafting a robust assessment criteria: Establishing a clear and unbiased framework for decision-making is crucial. Consider the different personas who will use the solution, and develop a comprehensive list of features. Don’t forget the mandatory requirements such as security and data protection, which may be necessary for your customers. This foundation will drive the decision-making process, so it’s essential to invest quality time in this step.

2. Need for Speed vs. Personalization: Buying a solution offers the advantage of getting started almost immediately, with most vendors quoting a 6–8 weeks onboarding timeframe. However, the value of purchasing a standard solution diminishes if there’s a strong need for customization. Striking a balance between speed and personalization is key.

3. Removing the bias: It’s important to provide equal opportunity to all options on the table. A formal RFP process, where internal development teams bid alongside external vendors, can help achieve this. This approach allows for a like-for-like comparison, giving the customer an unbiased view of all potential solutions.

4. Integration capabilities: One common pitfall is being enticed by the quick start a SaaS platform offers, only to face challenges when integrating it into the existing ecosystem. The better a tool integrates with your overall application landscape, the more value it brings. Don’t underestimate the power of data access and the ability to integrate it for informed decision-making.

5. Evaluate long-term ownership costs: You may have always got lured by that $9 per user per month type license costs. It might seem like a steal deal, but be careful — it may or may not be. Conduct a thorough long-term ownership cost review, considering factors such as license costs, one-time fees, number of users, payment terms, and any clauses for cost increases over time. Similarly, calculate the costs for an internal platform, including ongoing development, maintenance, end-of-life upgrades, and support costs. It’s typically wise to project at least 36 months of ownership costs for the tools under consideration.

In the end, the decision to build or buy requires careful analysis, and it’s important not to rush through this process. While the appeal of a quick, off-the-shelf solution can be tempting, it’s crucial to ensure it can integrate seamlessly with your existing systems and won’t result in isolated solutions. Ultimately, there isn’t a one-size-fits-all answer — it’s about finding the right balance, where even a ‘buy’ decision must be accompanied by a strong focus on ability to integrate as and when required.

--

--

Ankur Mongia
Beyond Agile Leadership

A seasoned tech leader with 20+ years in asset mgt domain, driving global teams, digital transformation, tech strategies to boost client exp & maximize revenue.