The typical techie will face every challenge with a simple question: “Can I build the solution myself?” And often, the question is valid enough that it gets some significant consideration. So, should we build or buy? Evaluation of an incident management solution seems to now invite this question as well. But how do you know when you should build or buy your incident management platform?

Why Build?

Sometimes the desire to build your own solution is based on the simple fact that procurement of a commercial solution is out of your hands. For example, enterprise IT has the budget for the tool, but the DevOps team needs it. It may seem easier to build a solution from open source projects than to play the long-term games it takes to get a solution purchased. But this is an organizational problem, and not a technical one. And often times, the custom-built solution tends to be short-lived.

But there are other reasons why you might want to build your own solution:

• Real or perceived unique requirements
• Security and privacy concerns
• Cost

These are valid reasons to consider building your own incident management solution — but all need to be scrutinized.

Are your requirements truly unique? The way to identify if this is the case is to look at your competitors and what they use, and research your requirements compared to similar organizations. And at the same time, even if you have a unique requirement, you might want to question why it’s so unique. Does it need to be that way?

As for security, what is it about your security and privacy concerns that make them a no-go for commercial incident management? Is it the potential for exposed data? Most of the time, application data does not need to be included as part of alerts, but if it is, this is something to consider. If the concern is around security in general, keep in mind that vendors work to make sure they are current on security threats. Often, they have the capacity to be much more on top of security than internal operations teams.

And then there’s cost. Cost is tricky because the most expensive aspects of building your own solution are not easily calculated. It’s easy to calculate the monthly fee of an incident management service versus the cost to do one-time development from a full-time developer. However, it’s hard to anticipate on-going maintenance, feature changes, and the big one — opportunity cost. What would the developer(s) be working on if they were not building this solution? And what is the cost of having projects or backlogs put aside while it’s being developed? Another issue arises when the person who built it leaves, and takes the understanding of the code base with them. You don’t want tribal knowledge leaving the organization when it’s related to a mission-critical part of your infrastructure.

Do You Integrate?

Building an incident management solution has one particular weak spot — integrations. Successful incident management platforms have a huge library of integrations into sources (like your application and infrastructure) and distribution (like your collaboration tools). Building these integrations takes quite a bit of time, oftentimes requiring developers to learn and build against new APIs. Organizations who build their own incident management platform may only have to work with integrations that matter to them, as they don’t need to support many use cases. But when the APIs for these systems change, you can be blindsided — miss out on new functionality or break the platform altogether. Open source projects are not going to respond as quickly to changes in integrations or create new ones, and if something breaks, your developer, already tasked with something else, would have to drop everything and address it. And of course, the choice of tooling that your incident management system must integrate with may also shift as the team scales and its needs change.

When to Build

There is a scenario where a custom-built incident management platform based on open source projects is useful, and that’s when it is required for purpose-built, very niche scenarios. Generally, organizations that need such a solution would have commercial incident management for the global environment, and roll up or even integrate into the incident management platform’s API for the niche scenario.

The other purpose might be for alerting that is used in a different context than for application or infrastructure support. Perhaps the alerting is used for collaboration or product management. In such cases, it might be useful to segment the use case from the commercial and mission-critical incident management system with a more homegrown and less liable system for the other use cases. This can be true for teams that already have a lot of customization when it comes to learning from their application usage. For example, when a new feature is launched you can elect to receive alerts when that feature is used, or when new infrastructure is rolled out you can choose to be alerted when you hit a certain KPI in performance to understand the impact of the changes.

The other reason is data leak concerns, both internal and external. For example, alerts where remediation exposes personally identifiable information to internal tier 1 support, but they do not have the authority to see. This could be an issue, especially in regulated industries. Nine times out of 10 you can modify your roles in the platform and what is exposed, so this is never a problem. In general, you should always try to do that. But there are the rare instances where it is unavoidable.

Your Time to Shine

A seasoned techie will know when it’s the right time to build or buy, beyond their interest to tinker and solve problems. The initial creation of the solution is not where you get stuck. It’s the long-term support, and risk associated with custom solutions. And it’s not just the creation of the solution — you also have to run it. Do you install an incident management system for your incident management system? Having to worry about the uptime of something else is stressful, and if incident management goes down, you are flying blind.

Custom niche integrations into your code base and infrastructure sometimes justify building your own incident management solution. Or if you have non-mission-critical use cases that are tangential to your commercial incident management, it may be worth the effort to build your own. In general, though, a commercial solution will have a lower total cost of ownership, will address your needs as you scale, will ensure that tooling and processes don’t break down when certain experts leave, and will have better coverage and solutions for your security and privacy concerns.

When deciding to build or buy, I suggest focusing heavily on the opportunity cost. This is the greatest unknown and expense, and usually, the answer becomes clear pretty quickly.