No USB cable, unfortunately, is long enough to stretch from Spain to Australia (thank goodness—think of the untangling nightmare). Which is why we at Bugfender started experimenting in the summer of 2014 with ways to debug iOS and Android applications remotely.
We tried using services like Papertrail and Logentries, crash reporting tools like Crashlytics, and we even tried to hack what we needed into Google Analytics. But none of them provided what we needed: the raw log files from the mobile apps, grouped by user or device.
This is the inside story of how, over the past 3 years, we built Bugfender.
- Why we decided to build Bugfender.
- How we almost gave up.
- How our marketing strategy went from totally perplexed to a blueprint for success.
This post is the first in a series of quarterly updates in which we’ll pull back the curtain on our metrics and learning experiences.
Life, Fending off Death and the Comeback
Here’s our original estimate from 2014 for how long it would take to develop Bugfender:
- iOS + Android SDKs: 6 days
- API + Database: 3 days
- Web Admin: 3 days
- Total: 18 days (roughly 4 weeks of work)
So yeah, we underestimated that one a little.
Other priorities came into play, and it took us 4 months until we had our first internal alpha version of the SDK ready in November 2014.
We then carried out a further 4 months of testing before we considered it stable enough for public use in March 2015.
We wanted to see if there was demand for our product, so at first we offered it out completely free of charge. Finally, in September 2015, we rolled out paid subscription tiers and our first paying customers soon followed.
Fast-forward one year, to June 2016: 17 paying customers. A Monthly Recurring Revenue (MRR) just below €1000/month. A burn rate of €3-5k a month spent on development, data storage, customer support, and marketing expenses.
It doesn’t take an accountant to work out that we were talking about killing the product.
But we didn’t pull the trigger. Summer had arrived, and we decided to postpone the decision ‘till after the break. It was a good decision, too—we started to see month-on-month growth of 10-30% as a result of our marketing efforts.
As of today we have around 78 happy paying customers, among them some significant consumer companies and brands.
Let’s crunch the numbers. Here are some stats as of March 2017:
- There are 2149 users, 79 of which are paying customers (3.7% conversion rate).
- There are 9.5M devices with the Bugfender SDK installed.
- The app is collecting over 50M logs daily.
- The app is detecting and reporting 20k issues daily.
- Money saved for our customers? A lot! Engineers who used to spend hours hunting bugs via trial and error can now do so easily using Bugfender Issue Reporter. We help detect bugs early on so they can be fixed before they reach a userbase of millions.
- Money made for our customers? It’s hard to give an exact figure as we have no way to track this directly. However, from the feedback we get, and from indirectly tracking our customers’ App Store ratings, we know that Bugfender boosts App Store rankings by supporting the development of less buggy apps. The customer satisfaction rate, therefore, is much higher.
- Founders’ money: €24,000
- EU grant: €90,000
- AWS credits: €10,000
- Time investment: 3,500 hours by the three founders. Assuming a reasonable hourly rate of 25€/hour, this amounts to another €87,500.
- Total investment: €211,500
- Net revenue: €42,345 (since September 2015)
- Current MRR: €4,612 (as of March 2017)
- Hosting (Amazon): €2,000
- 3rd party services: €500
- Development: €3,000
- Marketing: €3,000
- Founders' salaries: €0
- Total monthly expenses: €8,500
- Monthly Recurring Revenue (MRR): €4,612
- Monthly Expenses: €8,500
- Profit: -€3,888
We’re still investing heavily in product development and marketing (around €6k/month). Without this cost the business would theoretically appear profitable, but we still have 3 founders without any kind of compensation. Assuming a reasonable salary of €4k per founder per month, we'd have to add another 12k€ to the monthly expenses.
Hate Marketing? You'll Love Our Approach
We’ll come clean: we're engineers at heart. So when it came to marketing, we thought we’d stick a few paid ads on Google and Facebook and the new users would come a-clickin’. Better than nothing, right? Well, the truth is we ended up burning a lot of money month by month, without any tangible results.
Here’s what didn’t work:
- Paid traffic (advertising) on Google, Facebook, Twitter, and LinkedIn.
- Sponsoring developer conferences.
- Sponsoring developer newsletters and podcasts.
Here’s what did work:
- In-depth, insightful blog posts.
- Answering questions on Stackoverflow and Quora.
- Comments on Hacker News and Reddit.
Learning takeaway? Developers are a discerning bunch—you can’t just bombard them with ads and expect them to buy. What really turned heads was the expertise demonstrated in our authentic comments and blog posts. What turned our heads was the fact that we never intended to market our product by doing so.
Which translates into good news for us; we hate selling and marketing, but we love helping other people within the developer community. So, in the following months, we’re going to focus our "marketing" efforts on providing genuine help, and creating original and valuable new content.
What does this mean in practice?
- We continue our personal involvement on developer community sites.
- We forget about cheap outsourced blog posts, and focus more on in-depth, insightful blog posts. They take a lot more time, but are also a lot more fun to research and provide real value for our readers.
- We're working on an ebook called "Down to Zero" which will reveal the top logging and debugging strategies we've developed over the years as mobile, web, and backend developers at Mobile Jazz.
- Instead of simply sponsoring conferences and podcasts, we’ll do conferences and podcasts. We've got loads of valuable knowledge to share and many interesting stories to tell.
Truly Technical Support
Acquiring new customers is one thing—providing extra value for existing customers is another. We believe Bugfender is a great product, but it's far from perfect. Not only that, but different people have different needs and expectations.
Early on, we realized the importance of quality customer support. People were telling us that Bugfender was a great tool, but they were also telling us that our quick and competent responses were something they hardly ever experienced anywhere else.
Because of this, and because demand for customer support was growing, we decided against cheap outsourcing in favor of support directly from our engineers. Since our customers are almost always developers, their needs are rather technical. It makes no sense having someone in a call center reading a protocol that instructs customers to turn their computer off and on again.
Is this model scalable? Time will tell. But so far our almost non-existent churn rate and positive feedback from customers prove that we're doing the right thing here.
Our current website does a good job when it comes to explaining Bugfender. On a more emotional and visual level, however, we felt like we could do better.
As a result, we’ve spent the past 3 months rethinking, redesigning, and rebuilding the Bugfender website. The result is a not only a slick new design, but also a brand new visitor experience featuring our new Bugfender heroine, Blair.
Here’s a sneak peek of what to expect in just a couple of weeks.
We're currently working on the release of Bugfender 2.0, which includes the following:
- The new Bugfender Web App with:
- Improved UI.
- Improved device search, with additional filters.
- A search feature inside the log viewer.
- The ability to view logs between specific dates.
- The option to enable devices based on rules.
- App performance tracking.
- macOS SDK.
- tvOS SDK.
Following the release, we have a number of ideas in the pipeline. Anything here stand out? We’d love to hear from you.
- Automated crash reporting.
- Automatic logging of network requests and responses.
- Windows SDK.
- True real-time logs.
- Issue aggregation.
- User-submitted feedback.
- Mobile database access (SQLite, CoreData, Realm).
- GitHub, Bitbucket, and GitLab Integrations.
- File upload / attachments.
You might think with all this on our plate we’ve had little time for new innovation. We’re pleased to say, however, that here at Mobile Jazz we’ve been beavering away on a side project: Localname.
It’s an easy to set up tunnel for mobile and web developers to improve live collaboration between remote team members. We just launched the website and are taking registrations for our private beta.
The Bugfender Blueprint
We believe our story can inspire those wanting to create a product that’s special and successful:
- Identify a problem, then fix it. Chances are, there are thousands of people out there waiting for a solution to the same problem.
- Be patient. If you believe your product is good, push it before pulling the trigger once and for all.
- Marketing has many hats. Focus on the best way to make your potential customers happy—this might just be your best marketing tool.
- Customize customer support. Provide technical expertise for customers who are technically adept.
- Don’t stand still (your competitors won’t). Keep innovating and improving your product through a variety of channels.
We’re optimistic about the future, and that Bugfender will get even better at helping customers create world-class products and services. Join us for the journey—we’ll be completely transparent about what we learn along the way.
This series of posts document a high-level process to use when planning a modern web application, from project organization, collaboration considerations and tooling choices during development, all the way through deployment and performance strategies.