Should you build and maintain your own crash reporter?
July 7th, 2020 Joey the PM
You’re in the process of creating and launching new software and you want it to be as stable as possible.
maybe your software has been running for a while, but you’re frustrated with the bug-reporting workflow in
Either way it’s time to look for a crash reporting process that fits your application.
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
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.
Does your team have the development capacity to build a crash reporter?
How long will it take to build?
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
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
mission, pushing back deadlines, and creating new difficult work for themselves. It doesn’t matter what
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
your own on top of your original (and prioritized) product can result in a laundry list of unexpected
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
how their solution could
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
on your most
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
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
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
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
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
built to improve the process of crash reporting. We are dedicated to building, maintaining, and improving
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
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
sacrificing the time and energy of your developers.
Let’s assume that you have decided that building a crash reporter was a worthy endeavor and that you’re
concerned about missing out on all the features a third-party tool would provide. What would it cost to
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
of time they are likely to spend maintaining your solution times the amount of time your project will
be actively supported by your team.
The average annual salary of a developer in the US is roughly $100k. Maintaining your proprietary crash
could easily be a full-time job for a large application - but let’s assume that your application doesn’t
quite that level of diligence. It’s still going to be a significant part of any developers job maintaining
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
This adds up fast in real costs to your business. Outside of the initial investment to implement your
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
easily spend maintaining your custom solution.
Larger software applications have an average shelf life of 6-8 years. Maintaining your solution over the
of the lifetime of an application adds up to tens or hundreds of thousands of dollars.
Note: we use the
calculator from Omni Calculator to help us evaluate
tools we should build. Like you, we're engineers who love building tools. Sometimes we get carried away.
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
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.
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
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.
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
integrating these libraries, and our users find BugSplat suite of analytics and debugging tools critical
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
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
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
team can accomplish.
Stay up to date
Subscribe to our newsletter to get all new posts and updates sent to your inbox.