When we think of other products in Bugfender’s space, we don’t really think of competitors; we think of alternatives. Because, being honest, Bugfender doesn’t really have any direct competitors.
That sounds like cheesy marketing, right? Yep, we get that. And we don’t say it to be arrogant. We say it because Bugfender was built to provide a unique service in our space. In fact it’s designed to serve the specific needs of our parent company, Mobile Jazz. That was all it was at first: an internal experiment. Built for us, by us.
Now we’re a bit more savvy, and we realise we’ve built a really cool product. Bugfender is a holistic error-management tool that offers logging, crash reporting (and soon user feedback) all in one solution. No other solution, to our knowledge, offers all these functions in one package.
But rather than give you all the key selling points, like a marketing brochure, we’d rather tell you a bit about how Bugfender came about, and explain the product as a story. Obviously we hope that the developers reading this blog try out our product after reading this post (if they haven’t already), but if they prefer to use alternative products such as Instabug and Crashlytics Log, that’s cool. We still use them ourselves.
The article is primarily intended to provide an interesting read, and hopefully inspire our fellow developers to build out their own internal experiment into a commercial product. That journey is as big a source of pride for us as the product itself.
Ok, well that’s quite enough preamble. Let’s get into it.
How Bugfender Started
Some products are built for a dream; others are built for a need. Bugfender definitely falls into the latter category.
We didn’t build Bugfender because we wanted to invent the next Facebook or Google. It was a response to the problems we faced on a daily basis. Specifically, we were tired of those ‘but it works fine on my machine’ issues: bugs in our applications that didn’t appear on our own devices.
When these bugs appeared, the only way to fix them was to get physical access to an affected device. Or, if that wasn’t possible, call an impacted user and ask them to describe the problem to us.
Both of these had obvious drawbacks. It was pretty difficult to get hold of a device if the user was thousands of miles away: it was even more difficult for our users to describe some of the nefarious bugs they encountered.
So we decided to build Bugfender. The solution we designed was an SDK, which could be added to our apps during development. When a user downloaded our app, the device’s NSlog or Logcat files could be sent automatically to our servers.
The logs would be stored in the cloud, so we needed to build a web-based management tool to view them. This is really the core of the product: we built our web console with powerful filters, so we could narrow our search down to very specific groups of devices when fixing problems. We could even focus on one individual user if the problem was limited to them, something we weren’t able to do with tools like Crashlytics or Instabug.
Our design offered three key advantages:
- Universal reach. Whereas previously we’d been tormented by rare and inaccessible bugs, our logs now enabled us to replicate any error, from any device. There was no need to ask to see our clients’ devices anymore, or waste their time by asking them to describe the problem to us.
- 24/7 Coverage. The logger would run continuously, unlike other products. We even designed it to retain logs when the device was offline, and send them over when a connection was regained. So now we could pull pretty much any information we wanted about our apps’ performance. Our solution was proactive, not reactive like its alternatives. We weren’t responding to crashes anymore: we could actually see them coming.
- Individual user targeting. Through Bugfender’s site, we could search for specific users, timeframes and device models. So if a bug had bitten only a small number of users (which happens frustratingly often), we could narrow our focus to those users and devote our energies to them.
Commercial Roll-Out
After a few months of happily using our new creation and tweaking it, as developers love to do, we had a lightbulb moment: why not roll this out commercially? If it benefited us, it must surely benefit other developers too.
To sweeten the deal, we added a crash-reporting feature, which dovetailed perfectly with the remote logging aspect. Some crash reporting packages like Crashlytics simply tell you that an app has crashed and provide the basic details, but don’t reveal why it has crashed or what actions led to the problem. Bugfender, in contrast, could report a crash and unravel its causes.
After a slow start (caused partly by our own inexperience in marketing) Bugfender has really caught the imagination of the development community. The product has been installed on over 10 million devices, and the number’s still heading north.
We’ve just updated our product with a new version, which we’ve given the very original name ‘Bugfender 2’. The combination of logger and crash reporter was already a stand-out, and with our upcoming user feedback feature also coming on-stream, it’s an all-in-one tool. User feedback can help to illustrate the exact instance visually, providing the developer with even more context.
We recognise that there are plenty of great crash reporting tools out there, and a handful of logging solutions. A lot of our clients use these programmes already, and we’ve built our product to be 100% compatible with them – so Bugfender can help to ‘fill in the gaps’ that these services aren’t already offering. We don’t think we’re better than these solutions. We just think we’re different, that’s all.
