3 questions to ask in the build vs buy debate for incident response tooling

As a former incident responder and now as a responder advocate for FireHydrant, I’ve seen the “build vs. buy” debate play out many times. In fact, I even supported the tool that former employers used for managing incidents for years before they decided to buy (more on that in a future blog post).

In my experience, the story usually plays out in one of two ways:

1. There’s a major incident and “reliability” becomes a focus area for investment, or

2. One person sees the benefit of automating some of your incident response tasks and decides to take it on as a pet project. 

In either scenario, the allure of “build” is strong, and thoughts of, “I can be the hero!” and  “My company has such unique use cases that no out-of-the-box product will do!” may start dancing around in your head.

However, I’ve found that in many cases, there are components that will go into building — and then running — these tools that might not be fully considered. These are three most common ones I see come up.

Are you ready to build a product?

What might seem like a 10% effort project will end up being much more time consuming than you think because, when it’s all said and done, you’re talking about building an actual product. It might only be used internally, but it’s still a product.

That means that once all the work that goes into building your tool is complete, the work isn’t even close to done. Just like with a product, your tool will need to be updated, enhanced, fixed, etc. Not only will someone need to keep the management tool running, but someone also has to train people on how to use it, and ensure it can scale as your company does. 

And after all of that, what happens when an incident occurs and you need to use that tool? If it’s built using the same providers and tools that your core product uses, it might be down too.

By buying something, you not only save yourself more hours than you think, you’re also receiving a roadmap of additional features you might not have the capacity to build (or maintain).

How much is your team learning from incidents? 

Although incidents can feel painful, they have an upside. They provide insights that help you better understand and invest in your product, customers, people, and processes. If you’re busy building and running a tool, you have less time to devote to learning during and after the incident.  

To truly move forward in the nebulous goal of “being more reliable,” you need two things: a streamlined incident response process that helps you resolve incidents more quickly, and the commitment to learning from incidents and using those learnings to improve your systems. And in the best cases, one begets the other. 

Incident management tools provide you with out-of-the-box automation around assembly and communication that help you get to actually fixing the problem faster. But then the best ones help you automate gathering information for the incident retrospective and track trends around your incidents through analytics. Ultimately, these are the areas that are going to help you get off the incident treadmill.  

How much incident expertise exists in your company?

Five years ago, off-the-shelf incident management tools didn’t exist. Now, just like with your observability and monitoring tools, there are experts who are devoting their entire careers to building all of this for you. 

Opting for the “buy” option gives you the added expertise of people who are thinking about incidents all day long. Companies like ours are dedicated to improving their incident management tools, and ensuring the scalability, flexibility, and availability of their product. This extends to thinking about use cases and additional features to enhance your experience, things that might not ever occur to you.

Are you building or buying? 

If all you’re looking to do is automate a few things and you have the resources for building your own tool, it might be worth a try. There are open-source tools and IFTTT-Slack integrations that can make automating a few simple processes easy. But anything beyond that and you get into expensive territory that takes precious development hours away from your core product.

When thinking about building vs buying, think about the full picture. Scope the process out like you’re truly building a product — because you are. 

At FireHydrant, we believe so strongly in leveraging the expertise of industry professionals to make your incident response program more efficient that we offer an always-free version of our incident management tool. And if you’d like to chat about what build vs buy looks like for your specific use case, hit me up on LinkedIn.