I used to work with a colleague who constantly lamented how overwhelmed he was by the sheer number of platforms and tools he had to support. It didn’t make sense to me at first, none of these tools were custom-built, yet they were all self-hosted on virtual machines, requiring constant maintenance. With so many modern SaaS solutions available, why were we still managing everything in-house? It got me thinking: why do companies still grapple with the “buy versus build” decision, even when sometimes, outsourcing is the obvious choice?
When deciding between building a custom solution or buying a SaaS product, there are several important factors to consider. This is a straightforward question, but it’s multi-layered and requires discussion due to the differing viewpoints involved.
The first thing to examine is the effort needed to support whatever solution you choose. If you’re part of a revenue-generating function, you probably have the resources to support a large team, allowing you to develop solutions as needed. In that case, building custom software may make sense. However, for organizations operating on tighter budgets, like a startup or an IT cost center, cost becomes a critical consideration.
Cost can be broken down into two major components: personnel and operational. Full-time employees represent a significant, long-term investment, which can be a good thing if it means you retain institutional knowledge. However, in periods of economic uncertainty, such as the 2023-2024 industry-wide layoffs driven by rising interest rates, companies quickly realized the strain that high headcount could place on their budgets. Headcount freezes and layoffs became common, leading many organizations to reconsider how they could still create value under these constraints.
One way to address these challenges is through strategic outsourcing. If you think about it, SaaS solutions are essentially a form of strategic outsourcing, as they allow you to offload not just development but also infrastructure and ongoing support. Instead of maintaining a full-time team to build and manage a product, you can leverage a SaaS platform, freeing up valuable personnel for other tasks.
Now, when we talk about SaaS versus custom-built solutions, the spectrum of options is vast. You might go for vendor-hosted SaaS, which minimizes operational responsibility, or choose heavily customized commercial off-the-shelf (COTS) software that fits your exact needs. Then there’s the question of where to host these solutions: whether on bare metal, VMs, containers, or even Kubernetes. This flexibility means you can match the deployment model to the skill sets available in your organization.
To decide which SaaS products to use, consider a few things. First, look at common use cases. Areas like development tools, or enterprise support functions like finance, HR, learning and knowledge (L&K), often have well-established SaaS solutions that are fit for purpose. When you go down the custom-build route, it’s typically for unique, industry-specific or organization-specific use cases that aren’t easily solved by existing products.
Another critical factor is total cost of ownership (TCO). SaaS products may seem expensive at first glance, but you need to ask whether you’ve properly accounted for the full feature set and the development and maintenance effort that custom-built solutions require. Sometimes, people underestimate the costs involved in building software, especially when trying to use offshore resources or ignoring long-term maintenance.
Skill set is another consideration. Even if a SaaS solution seems to check all the boxes on paper, if the user experience is poor and it requires extensive training for your team to use it, that’s not a great fit. In such cases, a more customized solution might be worth the investment. But if you end up spending 50% of your time on custom development and the other 50% on training, that’s a waste of resources.
When you host your own solutions, you’re responsible for everything—OS management, high availability, disaster recovery, and more. This is another reason SaaS is appealing: it covers not just development, but also infrastructure, updates, and support. In today’s environment, where cloud services and managed solutions are readily available, there’s less reason to manage everything yourself.
This ties back to that story from earlier. My colleague’s team was stretched thin, spending all their time on server management and maintenance instead of delivering business value. A SaaS solution would have freed up their time and allowed them to focus on more impactful work. This example highlights one challenge many organizations face: they simply lack the people and resources to support all the tools they’d committed to.
On the flip side, there are cases where in-housing makes sense. For example, Coinbase brought its observability suite in-house after determining that their Datadog costs were too high. By developing their own solution, they were able to halve their expenses. But in-housing only works when there’s a strong business case for it.
A common mistake when making architecture or technical decisions is focusing solely on features without considering other factors, such as community support or long-term viability. You don’t want to select a supposedly cheap open source technology, but end up having to spend millions later to fix risks or issues caused by it. You also have to think about your team’s skill set. There’s a balance to strike between choosing a tech stack that’s powerful but harder to support and one that’s easier but perhaps less cutting-edge. At the end of the day, you don’t want your tech choices to be “driven by HR” (aka only by what skills are available for hire), but you also can’t ignore the impact of skill decisions on your staff.
Ultimately, whether you buy or build, the main point is about delivering value. Buying software often delivers value faster and with less overhead, but it can come at a higher price. Building may give you a custom solution, but it demands significant investment of resources in terms of both development and ongoing maintenance.
A key insight is that code and infrastructure, whether on-premise or cloud, are sometimes seen as assets, but I believe they should be treated as liabilities. These are things you take on, responsibility-wise, in order to deliver value, but the less of them you need, the better. The ideal situation is to deliver value without building or maintaining any software, infrastructure and cloud assets yourself, although that’s only rarely realistic. So, the question becomes: What is the minimum amount of custom software and infrastructure you need to deliver your solution? As our technology has evolved, we’ve moved from managing bare metal servers to spinning up VMs and even containers, reducing the management overhead at each step.
Serverless technology, like AWS Lambda or Azure Functions, represents the next level of abstraction. You give up control over the platform, but in return, you gain efficiency and reduced operational burden. These platforms are designed to scale automatically, reducing the need for constant maintenance and monitoring.
Cost should also act as a guiding principle for your architecture. If a solution is technically elegant but too expensive to maintain, it’s not the right choice. On the other hand, choosing to self-host a complicated solution with a high maintenance burden may also not be the best use of your resources. You need to balance capability, cost, and maintenance when deciding whether to buy or build.
The decision between buying and building is not binary. There are a range of options within both categories, each with its own pros and cons. The right answer depends on the specific needs of your organization, the available skill sets, and the long-term costs involved. By focusing on mainly delivering value, rather than preserving job roles or minimizing short-term costs, you can make a more strategic choice that benefits both the organization and its employees.
Featured Photo by Piret Ilver on Unsplash
