Bugfender Growth: from side-project to a sustainable $20k MRR business

It’s nearly five years since we started Bugfender as an offshoot of our software company Mobile Jazz. We’d gotten tired of chasing users who were experiencing problems with our apps and wanted to build an internal remote logging tool that would feed the information straight to us.

It really was a garage project back then. We were running code sprints on our own time, so we wouldn’t have to dig into our savings. But we soon realized this could be much more than an internal experiment. In fact, it could benefit the entire software industry.

Since then we’ve built Bugfender into a viable business, with its own team and roadmap. We’ve secured a full range of customers all over the world, from indie and freelance developers (ping us for a discount if you’re one of those!) to multinationals with dozens of devs. Our co-founder Stefan did an interview with Indie Hackers in March 2017, at a time when revenue stood at $6,500 per month. That number has now more than trebled to $20,000, on a recurring basis.

In this article we’ll provide a series of tips to sustain your startup’s initial growth rate and build something that lasts. We’ll discuss the bad decisions we’ve made as much as the good ones — because trust us, we’ve made plenty. If you’ve got a project of your own and want to turn it into something more established, we hope the article at least provides some food for thought.

Tip 1: Don’t become a hostage to your business plan

Having a plan is great. Simply putting it together forces you to consider the bigger picture, which is crucial when you’re starting out. But it’ll soon become outdated.

Growth figures, profitability estimates and milestone dates will be flawed from the moment you commit them to paper, so it’s better to be prepared for the moment you realize you haven’t followed them.

As indie hackers, we have the freedom to adapt our business every single day, and we should constantly remind ourselves of this (as well as our co-founders, team and customers!) Unlike companies backed by venture capital, we can react to events and change our strategy. It’s a crucial advantage.

Tip 2: Avoid direct marketing — talk to users instead

Before launching Bugfender we’d read tons of lovely growth stories, illustrated with charts whose parabolas arced skywards like laser-focused hockey sticks. But our own journey wasn’t quite like that.

When we started making some money, we thought we could take our linear growth track and bend it northward, simply by throwing cash at the problem. Exponential growth? We’d just hack our way there, no worries!

Suffice to say we got that wrong.

We never had (and never will have) full-time marketers, so when we started spending money it was really a case of trial and error. We relied on growth hacking bibles like Traction, but didn’t have any real expertise to call on. Unsurprisingly, a lot of our ideas didn’t work.

We found that ‘traditional’ marketing strategies aren’t really appropriate for our audience, which mainly comprises other developers. As readers will be aware, developers are a rather cynical bunch! Search ads, display ads, sponsoring newsletters, creating affiliate networks… you name it, devs have seen it all before. And they don’t want to see it again.

The one thing we’ve found really successful, which we’d recommend to any other software startup, is writing relevant blog articles for our community. We’ve strived to offer genuinely helpful articles which offer developers interesting takeaways. That way we’re adding value to the wider ecosystem. Instead of selling a product, we’re sharing our knowledge, and it seems this has contributed directly to our growth.

We also maintain contact with the community by attending events, answering questions on online forums and contributing to the global knowledge base via our open-source libraries. Above all we pride ourselves on providing excellent customer support, which is a real differentiator in our space.

Tip 3: Keep your customer service personal

In fact, while it might sound strange from the CEO, I still handle most of the support myself. I actively ping and prod customers into asking questions, suggesting things… basically contacting us for anything they might need.

On a personal level, it’s something I really enjoy. I’m a developer myself and love talking about the nuts and bolts of coding, getting into the weeds. But, in a customer-centric world, it also makes business sense.

By engaging with our customers we’ve been able to understand what they need, what works and what doesn’t, what they love and what frustrates them. A great deal of the changes we’ve made to Bugfender came directly from user feedback.

Analytics tools can provide a certain level of insight, but direct customer feedback is even more beneficial. We’ve found that, if the question is relevant and quick to answer, customers are always happy to answer you.

Tip 4: Add the features the market wants

Drawing on this insight, we’ve piloted Bugfender towards a more holistic pathway, turning the original logger into an all-in-one error management solution, for devs like us. We’ve enhanced the product by sifting through the reams of requests we’ve received, identifying the requests which are financially feasible and chime with our overall vision for the product.

Remote logging is still our core focus, of course; we’ve burned many barrels of midnight oil to improve things like the log viewer. But we’ve also added a crash reporting feature and a user feedback form, which allows the app’s users to report bugs and design flaws.

We’ve also gone beyond our original base, which supported only native iOS and Android apps. We now provide ready-made integrations for platforms like Cordova, Ionic, React Native, Xamarin and Flutter. These SDKs are nothing more than wrappers of the original native SDK, but save developers time and keep our audience growing.

We’ve also built integrations for the most popular iOS and Android logging frameworks like CocoaLumberjack, Log4j, Timber, XCGLogger and SwiftyBeaver, as well as integration points to a developer’s application backend or other tools they might be using. For example, if they’re using Intercom for customer support and the support agent wants to check Bugfender logs, they’re just one click away.

So now we can reach a whole new range of users and we’re in tune with the times. More and more devs are platform-agnostic, moving away from native apps, and we wanted to remain in step, not because that’s the “hip” thing to do but because our focus is on staying relevant — as it will be for any startup entrepreneur.

In the end, it comes back to listening to your audience. They’ll tell you, loud and clear, where they want your product to go.

Tip 5: Only change the technology when you need to

We may have added loads of new features, but the tech stack’s remained pretty simple. In fact we haven’t changed a lot of the fundamentals since we started. If something’s working, we don’t see the value in changing.

For the back end we’re still using Go. Yep, we hear you: it’s not perfect and never has been. We kind of chose it at random, if we’re honest — there certainly wasn’t any outstanding feature which informed our decision. But over the past five years Go’s developers have made a lot of improvements, such as the addition of a dependency management function (first via vendoring on version 1.5, later with modules on 1.11), and the performance of garbage collection, which used to make our servers go belly up during heavy loads. There are still some teething problems, like the lack of exception handling and generics, but we’ve found that Go can handle our growing load — and we don’t need big servers to run it.

We’ve also kept using AngularJS, which might seem even more dubious because it’s so old! The simple reason is that, having made a number of efficiency customizations, it wouldn’t be worth our time migrating to a newer version of Angular. I certainly wouldn’t recommend AngularJS to anyone starting from scratch, but it does the job for us and we think it will continue to do so.

That’s not to say we haven’t made changes. On the front-end, we switched from server-side rendered HTML to client-side rendering and this really improved loading times, creating a more agile experience for devs and supporting the “live tail” functionality of the log viewer, which lets you see the logs for a device as they come in. We’ve also tweaked the infrastructure, moving from a custom deployment solution, based on cloud servers set up with shell scripts, to a Docker setup with Rancher.

Docker has helped us maximize our resources, improved our portability, sped up our deployments and rollbacks and made testing easier by replicating the production environment much more easily. The portability was a necessary ingredient to migrate from Amazon Web Services to our own datacenter, which helped us cut hosting costs by more than half.

We’re currently experimenting with Kubernetes and we expect to deploy it to production soon if everything works out.

Tip 6: Hire people proactively

As we’ve highlighted above, efficiency is our key watchword and this definitely applies to the hiring process. We don’t have vast resources and we can’t afford to grow too quickly, hiring too many people and then being left over-committed if we have a couple of slow quarters. The industry is littered with companies that have done that.

We’re lucky in that we can draw on the support of Mobile Jazz, which has provided a great source of engineers and technical support. But we’ve still had to fill a number of roles on our own (blog writers being a prime example). When we fill these roles, we’re incredibly specific in what we’re looking for. We don’t want ‘jacks of all trades’, we want specialists with demonstrable experience in their knowledge domain. What’s more, they have to be able to work remotely and be proactive enough to fit into a highly automated way of working.

So we’ve decided not to create an application form as such (although Mobile Jazz has an API-based hiring process). What we’ve done instead is go out into the market ourselves and approach people proactively. We’ve created specific profiles for the people we’re looking for, then gone out and found people to fit. We’ve gone through “friends and family” channels most often, but also used LinkedIn, as well as Slack and Meetup groups.

It’s definitely a strategy we recommend. There’s so much talent out there in the marketplace at the moment, and if you’re a fully remote company there’s no geographical limit to the people you can approach.

Some key takeaways

Here’s a summary of the stuff that may be applicable to your startup:

• Start with a plan, but do not obsess over it. Feel free to reschedule, reshuffle, add and remove things. Communicate this to your peers and don’t fret when events go off-script
• Spend time with your user. Participate in forums and write blog posts for them.
• Avoid or cut down on paid ads. It’s helped us save money with little impact on growth.
• Do the customer support yourself if you can. You’re the person who best knows the product, and it will help you understand your customer’s needs.
• Prioritize your customer requests. You’ll get thousands of requests once you’ve engaged your users, so think carefully about which ones make the most sense for you and your audience. Avoid the urge to “do everything” or you’ll end up with a product full of patches instead of something that fulfills a vision.
• Avoid shiny objects when choosing technology. Prioritize mature tools and migrate to newer/“better” versions when the change makes business sense.
• Pay attention when hiring. A good or bad hire will make a large impact on your business. Wait until you can financially afford to do so.
• Continuously adapt to the times, but always keep budget in mind. Choose wisely what to pursue, keeping your vision in mind.

And that’s it! If you want some more detailed advice, or just chat about our shared experience, just get in touch on Twitter @bugfenderapp. Hopefully we can learn from one another.