You’re in the process of creating and launching new software and you want it to be as stable as possible.

Or, maybe your software has been running for a while, but you’re frustrated with the bug-reporting workflow in place.

Either way it’s time to look for a crash reporting process that fits your application. This leads to a natural question: Should we build it? Or should we buy it?

To expand on this question, which will be better for my business? To dedicate development time from your team or to spend some of your company’s hard earned cash.

Short term: think in terms of resources

When considering building a crash reporting tool, you should ask yourself three basic questions.

1. Does your team have the development capacity to build a crash reporter?
2. How long will it take to build?
3. Can you afford to spend the time defined in #2 to building a crash reporting tool?

In an ideal world, you have excess development talent and flexible deadlines, as well as understanding and patience customers who desperately want to see you succeed.

If this is your scenario then you're exceptionally lucky. Most development teams aren't in this position.

For most, creating a custom tool means siphoning away precious development resources from their primary mission, pushing back deadlines, and creating new difficult work for themselves. It doesn’t matter what their mission is, to be successful teams generally need to be laser-focused allocating their company’s time and resources.

Take it from us, setting up a crash reporter from scratch comes with some complicated challenges, and building your own on top of your original (and prioritized) product can result in a laundry list of unexpected costs and issues.

By choosing a pre-built tool you automatically decrease your upfront cost, the benefit being your time to implement a solution time will be measured in hours as opposed to weeks.

This is because third-party tools generally have well-documented integrations which makes getting started relatively painless. They also almost always have free trials that allow you to get a real sense of how their solution could work for your team before asking you to make a financial commitment - shoutout to our free trial here.

If a third-party tool works for your team, that means your developers can immediatley get back to focusing on your most important product: the one you are building and selling to your consumers.

If it doesn't work for you then at least you've evaluated what is available before committing the time and expense of building a new tool.

Medium term: it’s all about your workflow

You did the math in your head and decided that it was easier to part with your excess development capital than it was to spend money on a third-party tool.

You are not alone - companies do this all the time for a huge variety of software tools and for a wide variety of reasons.

However, committing to proprietary tool means you miss out on one of the enormous advantages third-party tools have over their proprietary counterparts: large feature sets and powerful tooling.

Take for BugSplat for example-

It’s relativity straightforward to capture a minidump or some other crash dump file. Many programs have built-in hooks which allow you to obtain this data.

However, simply collecting a crash is not the value that we bring to our users. Our value lies in the tools we’ve built to improve the process of crash reporting. We are dedicated to building, maintaining, and improving our features so our customers can have exceptional analytics, in-depth data on each crash, timely alerts, etc.

To provide even a distantly similar experience yourself would require lots time from multiple developers - keeping them away from their primary responsibilities.

In the medium term, you lose out on features and added capabilities which a third-party tool provides while sacrificing the time and energy of your developers.

Learn more about the crash reporting workflow here.

Long term: evaluating the costs over time

Let’s assume that you have decided that building a crash reporter was a worthy endeavor and that you’re not concerned about missing out on all the features a third-party tool would provide. What would it cost to maintain this project? How do you evaluate it worth that cost?

A straightforward way to estimate this cost is to think of it in terms of developer salary divided by the percentage of time they are likely to spend maintaining your solution times the amount of time your project will likely be actively supported by your team.

The average annual salary of a developer in the US is roughly $100k. Maintaining your proprietary crash reporter could easily be a full-time job for a large application - but let’s assume that your application doesn’t require quite that level of diligence. It’s still going to be a significant part of any developers job maintaining the reporting solution, fixing bugs, and implementing changes or feature requests.

On the low end, your specialist is likely to spend a quarter of their time maintaining your proprietary solution.

This adds up fast in real costs to your business. Outside of the initial investment to implement your solution, dedicating a developer will cost thousands of dollars year-over-year to maintain something you could have purchased from a third-party.

At BugSplat our plans start at $49/month which is roughly 2% of the $25,000 worth of developer salary you’d could easily spend maintaining your custom solution.

Larger software applications have an average shelf life of 6-8 years. Maintaining your solution over the course of the lifetime of an application adds up to tens or hundreds of thousands of dollars.

Note: we use the Build vs Buy calculator from Omni Calculator to help us evaluate which tools we should build. Like you, we're engineers who love building tools. Sometimes we get carried away. This helps us decide which to tackle ourselves.

During this period, your solution will underperform compared to a third-party tool. This means that you're not getting the best data on crashes, putting your developers in a bad position to support your users and improve the stability of your application.

Moreover, what happens if the developer who maintains this solution leaves?

It happens all the time with tools that are custom built. One team member gets highly specialized in the maintenance and use - and because it’s not a mission-critical application, nobody else bothers to learn much about it. When this specialist moves on, you’re left in the lurch - scrambling to pick up the pieces.

——

How about a third-party open-source library?

Leaning heavily on an open source tool is also a tempting option. However, it comes with many of the same drawbacks as building a propriety tool from scratch.

Open-source libraries like Google Breakpad and Google Crashpad are useful tools for crash reporting. We’re big fans of them at BugSplat and offer integrations for both of them.

With open-source crash reporting tools, you do not get the detailed reporting functionalities of a third-party tool out of the box. They’re generally difficult to implement, lack an intuitive UI, and have no technical support team ready to answer your questions.

If you are looking to build a crash reporter, we do suggest that you lean on either Breakpad or Crashpad. It will decrease the development costs and provide some handy tools for capturing crashes.

However, we’d suggest you take a look at our Breakpad or Crashpad documentation. We’ve simplified the process of integrating these libraries, and our users find BugSplat suite of analytics and debugging tools critical for getting real value out of Breakpad and Crashpad.

In conclusion: where do you want to spend your energy?

The decision to build or buy any software tool generally comes down to this: is the solution required by your team so unique that the higher cost of developing and maintaining your own tool will cost less than buying one from a third-party?

Above we've given you our take on how to think about this decision when it comes to crash reporting and we think the choice is pretty straightforward - buying a tool almost always produces better results at a much lower cost. It allows you to focus more of your attention and mental energy on tasks which only you and your team can accomplish.