Turning an Internal Company Tool to a $6,500/mo Side Business
Hello! What's your background, and what are you working on?
Hi, I'm Stefan Klumpp. I'm originally from Germany, and though I've lived in California, Maui, Scotland, Barcelona, and Dubai, I've spent the past 3 years living out of a camper van.
I've done professional work as a car mechanic, an electrical engineer, a member of the Stanford self-driving car project (2007), and an iOS and Android developer (self-taught). But nowadays I'm primarily involved in product marketing and business strategy for Mobile Jazz. We're a 20-person remote team which mostly provides software development services for all kinds of cross-industry clients around the world, from small startups to big brands like Airbus, AVG, Google, HP, Skyscanner, and many more.
I work with two other co-founders: Jordi Giménez and Aleix Ventayol. Jordi started Mobile Jazz with me. He's worked as a web developer and security auditor for companies of different shapes and sizes. Aleix joined us later. He's an experienced CTO, full-stack engineer, and entrepreneur with more than 15 years of experience.
Internally, we make a lot of open source products and build internal tools, some of which turn into actual products. One of these products is Bugfender, and that's what I'm talking about today.
Bugfender is a remote logger and cloud storage service for application logs. Currently our focus is on mobile apps, but we're soon releasing SDKs for MacOS and web development.
Imagine one of your users encounters a problem (bug) that you cannot reproduce on your own device. The only way to look at it is to personally invite the user to your office to connect their device to your development machine. Not so easy — especially when you're in Europe and the user is in Australia.
Bugfender gives developers remote access to the logging facilities of users' devices. Here are some key stats on the product:
- We're currently making $6,500 (MRR), and we're expecting to be at $11k-$14k by the end of the year (2017).
- There are 2,616 users, 103 of which are paying customers (3.9% conversion rate).
- There are 12.5M devices with the Bugfender SDK installed.
- The app is collecting over 60M logs daily.
- The app is detecting and reporting 20k issues daily.
![[FIXME]](https://storage.googleapis.com/indie-hackers.appspot.com/content/bugfender__website.png)
What motivated you to get started with Bugfender?
As mobile app engineers we faced the problem of not being able to reproduce specific user problems on our own devices, be it due to a weird screen size, a strange OS version, or a specific setting. So we developed a really barebones version of this internal tool for remotely accessing logs, patched it into a special build, and began sending it to users that had a problem.
We saw that this was a recurring problem (which validated the idea itself) and thought it would be great to have the tool built in by default for all of our apps. However, sending so many logs, especially for apps with thousands or even millions of users, creates two problems:
- We'd have to transfer and store millions of logs per day, which is neither cheap nor simple in terms of scalability.
- If this service would always be running on the user's device, sending every log all the time, it would use a ton of data and could make their phone bills quite expensive.
To solve this we put a lot of effort into making this thing scale while at the same time reducing our traffic and data storage bills. (We're still rebuilding and optimizing things today.) And for our application-side SDKs, we put a lot of engineering thought into implementing a battery-friendly process for storing logs locally and only transferring them when requested.
What went into building the initial product?
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
- unforeseeable challenges: 6 days
- total: 18 days (roughly 4 weeks of work)
So yeah, we underestimated that one a little. Once other priorities came into play, 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 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) of around $1,000 a month. A burn rate of around $3-6k a month for 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 (June 2017) we have around 100 happy paying customers, among them some significant consumer companies and brands.
Recall that the founding team all worked on Mobile Jazz in the beginning. Well, as we began to see signs of traction for Bugfender, we began to slowly increase the hours we devoted to the product, decreasing the hours spent on Mobile Jazz.
We invested our own time and money (3 founders) and received an EU grant of €90k (a little north of $100,000):
- founders' money: ~$27,500
- EU grant: ~$103,000
- AWS credits: ~$11,500
- time investment: 3,500 hours by the three founders. Assuming a reasonable hourly rate of about $28.75/hour, this amounts to another $100,625.
- total investment: ~$231,125
We invested our own money and the EU grant mostly into building the product and constantly improving it. A good chunk also went — and still goes — into marketing. Finally, we spend a significant amount of money providing the best possible customer support by having our own engineers respond to support requests instead of outsourcing it. That would be a lot cheaper, but people love Bugfender because of the fast and outstanding customer support.
Initially we focused on building a functional product with enough functionality to test the idea in the market. However, we quickly realized we needed to focus more on the user experience: explaining the product better in the landing page, lowering the barrier for user onboarding (and then slowly revealing the application features), having a chat to interact with our users, building a knowledge base, etc.
There are a lot of things taken for granted around using a product as a user that are not so obvious when you're building one. This was the tipping point.
Can you tell us a little more about your tech stack?
Yep! We started development in Go (golang) as an internal experiment, and we also wanted to evaluate Go as a new language. While Go is a great new language, its novelty and lack of an ecosystem (relative to other, more established languages) caused several problems for us:
- unexpected bugs
- shortage of tools and open source libraries available for common problems (so we have to build everyone by ourselves)
- not many Go developers in the market yet (making them extremely expensive)
Our data is stored primarily in Amazon Aurora and Elasticsearch. We also use Redis for caching. We use Baremetrics for business metrics, Stripe for payment processing and Intercom for support. These products have saved us dozens of hours of development time.
Our software is currently hosted on Amazon Web Services although we're looking into Google Cloud Platform.
How have you attracted users and grown Bugfender?
This is the fuzziest part of Bugfender. We've tried a lot of things that we've "learned" from traditional marketing books, blog posts, and gurus out there.
To 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
Therefore, we decided 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.
What's your business model, and how have you grown your revenue?
Bugfender is a SaaS business. So we make money buy selling a monthly or yearly subscription to our service. Most people start with a free plan, but once they see the value and run into the limits of a free plan they start subscribing to a paid plan. Additionally, many then upgrade sooner to a bigger plan as, in the end, all the money they spend on Bugfender saves them a lot more money somewhere else. From our users' perspective it's a great investment.
We use Stripe as our main payment processor. We also offer PayPal, bank transfer, and even Bitcoin in a manual way to our customers (though, so far, only one user has requested to pay this way).
We're currently making $6,500 (MRR), and we're investing 100% back into the product and marketing. Also, we three co-founders aren't paying ourselves a salary yet. So the profit margin is zero or even negative, but this is on purpose as we're focused on growth and not maximizing profits at this stage.
Revenue is constantly growing (fluctuating between 5-30% each month). So even though we don't see a direct correlation between specific marketing efforts and sign ups (despite all the testing we do), we do see that they have a long-term effect. We therefore focus much more on building a brand and creating awareness for all of our products.
One thing we've learned, though, is that developers (our target audience) are smart people. They cannot be tricked into buying something with plain advertisement and a compelling message.
They're also excessively frugal. They use "free" as long as possible. They tend to underestimate the effort required to build something and sometimes try to build it themselves. However, if you address them in an honest, genuine, and authentic way, and once they see the value of something, they're great customers.
Interestingly, developers are our users and promoters, but the actual customer (the one paying for Bugfender) is their boss or company. So they might use the free version of Bugfender for themselves (hobby projects), but suggest the paid version for the companies they work for.
What are your goals for the future?
Our current goal is definitely growth. We're reinvesting all of our revenue into product improvements, exciting new features, giving the best customer support possible, and creating great content for marketing.
Our financial goal for the end of the year is to reach $11-14k in MRR, and we're very well on the way. But while having more money is always great, it's not what dictates the direction we take.
Feature-wise we're about to release a complete new version of Bugfender (v2.0), a MacOS SDK (beta), and crash reporting for iOS and Android.
In parallel we're already working on a better issue tracker and JavaScript and tvOS SDKs.
For the long term we've got a lot of things in our backlog, but we'll make them dependent on user feedback. That said, things to expect are automatic app performance tracking and getting a visual representation of the UI stack when an error occurs.
What are the biggest challenges you've faced and obstacles you've overcome?
Since we were already an established services company (Mobile Jazz) with a strong focus on company culture, remote work, and hiring talent, adding on another product was not a big challenge from a "human resources" perspective.
However, being a company that always has more work than it can handle makes it very difficult to decide where to allocate our resources Existing profitable businesses? Or into new experiments like Bugfender? If we'd known Bugfender would become such a success, we would have put more resources into it a lot earlier. On the other hand, we're not in a rush, and we prefer to do things the right way, even if it is a lot slower.
We also occasionally have heavy debates and even fights about technological choices. We're operating at an extremely high scale (12.5M devices and growing fast), and any decision we make has a huge impact on money. So everyone is quite involved when it comes to such decisions.
One of the biggest obstacles we have faced is that, being a development company ourselves, we've known how to build the product but not how to market it. We put a lot of effort in learning and hiring the right people, and we are still learning a lot every day.
Have you found anything particularly helpful or advantageous?
It was definitely helpful to not build a product based on just a hunch, but an actual need of our own. It is a small niche that we serve with Bugfender, but we 100% understand the problem and provide a perfect solution at a fair price.
I've personally been reading a ton of books, have been involved in great discussions on Hacker News, Quora, Twitter, and newer communities like Indie Hackers, plus various podcasts. It's hard to pin it down to one specific resource, but the vast base of knowledge and experience (mostly through reading autobiographies of other founders) that I've soaked up over the years helps me everyday in my decision-making process.
It also helped to quickly understand that targeting developers is not the same as targeting consumers buying laundry detergent in the supermarket. You have to really focus on building a product of the highest quality possible, in addition to providing superb customer support. This has gotten people to tell their friends and colleagues about our product.
We also just recently started sending out hand-written postcards to our paying customers (telling them how much we care that they're our customers), just to show them that we're real people behind Bugfender.
What's your advice for indie hackers who are just starting out?
Perseverance. We almost killed Bugfender because we only had very few paying customers and our expenses were exploding. Luckily due to the summer break and the successful application to the EU grant, we postponed that decision and, all of a sudden, growth started to rise rapidly at the end of summer.
Focus on a problem you fully understand. Even if it is a tiny niche. Everyone wants to build the next Facebook these days and gain riches and fame. But they ignore the obvious knowledge and expertise that they have in their own niche, where they understand the actual needs and problems.
Consider your choices when funding your startup. Raising money from angel investors and venture capital is just one of the options. But you can also find the required money by using some of your salary while working somewhere else (like we did) or reaching a special agreement with one of your first future customers where they finance it.
If you do decide to raise money, be mindful of how much you raise and when, and understand what you're giving away in exchange. We have seen people confuse business success with raising money from VCs.
Resources: a great book to give a good overview on marketing channels is Traction, by Gabriel Weinberg and Justin Mares. Other than that I'd just read and participate in the comments on Hacker News and Indie Hackers, and follow the right people on Twitter (e.g. Neil Patel, Pat Flynn).
