Bugfender is a tool to help developers debug their mobile applications by collecting the logs of their user’s mobile devices. It started as an internal tool, but Jordi and his co-founder saw a great potential and decided to turn it into a side business. They now have 165 paying customers, making a MMR of +€9,100/mo. Jordi does a little bit of everything at the company, from project management to back-end and iOS development, sales, customer support, setting up online advertisement campaigns, and writing content for their blog.
Bugfender is a tool that helps developers debug mobile applications by gathering records from the mobile devices of their users. Jordi and his co-founder saw its tremendous potential and decided to transform it into a side venture. They currently have 165 paying consumers, resulting in an MMR of +€9,100 per month. Learn how they built and grew Bugfender, as well as the errors they made.
What is your history and what are you focusing on currently?
Hello there! My name is Jordi Giménez. I once studied computer science in Barcelona, which led to employment in web back-end, web front-end, IT security, and other fields. My path has lately lead me to iOS and Android development. I was fortunate enough to co-found two enterprises in Barcelona, Mobile Jazz and Bugfender.
In addition to Mobile Jazz and Bugfender, we conduct experiments such as Localname, a service that gives your local development workstation an Internet-accessible URL, and DevCraft, a newsletter for inquisitive developers. Both are undergoing testing, and they may or may not become “something” in the future.
Bugfender is a tool that helps developers debug their mobile applications by gathering records from the mobile devices of their users from anywhere in the world. We collect the records and organize them in a streamlined interface that allows you to filter and view data by user, time period, mobile device manufacturer, and similar criteria. Bugfender allows remote access to the monitoring capabilities of users’ devices.
We began the enterprise with only three employees, but now we have nine. Bugfender is currently deployed on over 9000 applications and runs on over 46 million devices. In four years, we went from zero to $11,000 in monthly recurring revenue (MRR) with no outside investment.
I am responsible for a variety of tasks at the company, including project management, back-end and iOS development, sales, customer support, building up online advertising campaigns, and blog content creation. Every day is slightly unique.
Evidently, everything we do is self-funded. As proprietors, we are the only investors; we have invested our time rather than a large sum of money. After four years, our team has shrunk to nine members, some of whom are part-time, and we are extremely frugal with our finances. For instance, the objective of an advertising campaign is to create a product that people are willing to pay for. Because so many items are “free” in the sense that they do not cost money, our advertisements can be a bit confusing to potential consumers. Consumers must be aware that even with “free” SaaS products, they are still paying in some manner, such as being targeted with advertisements and having their data sold to the highest bidder.
In contrast, we seek forthright clients who value our offerings and are willing to pay for them. Fortunately, there are enough of these individuals for us to soon break even. We could have already attained break-even if we had ceased investing in the company, but we have chosen to continue investing above our revenue, despite the fact that this has a minor impact on our finances for the time being. Here you can view our numbers in real-time, as they are very transparent.
Additionally, the enterprise is completely remote. I am located in Barcelona, but my team is dispersed throughout Europe. We occasionally organize retreats or “workations” while working remotely. Early on, we realized that face-to-face meetings are essential for productivity and team development. Moreover, it’s just a lot of joy.
What is your history and how did you develop this concept?
I myself began mobile development in 2011. I was developing my very first mobile application for Android at the time: an application to monitor the balance on my prepaid SIM card. It was an experiment I conducted to understand more about Android. I was irked that my mobile phone provider didn’t have an app and that I had to constantly monitor their website to make sure my credit didn’t expire.
Therefore, I developed an application that utilized “web scraping” to retrieve my account balance from the website. Web scraping uses an application to log into a web browser as a real user, select the appropriate buttons to access the page containing the desired information, and then extract or “scrape” the information for your use.
It worked flawlessly for me. Since the operator lacked an app, I decided to make it public in the event that it would be beneficial to someone else. It turned out to be true. Within a few months, it attracted more than 20,000 users, a significant portion of the operator’s subscribers at the time.
The issue with web crawling, however, is that unlike humans, applications can be confused by routine alterations in the wording or structure of the displayed information. For instance, my application was used by both prepaid and contract users at the time, so the website appeared slightly different for each type of user based on the product, enough to damage my application.
To address this issue, I decided to create a small web service to which my application could send data if the content did not match expectations. Thus, I was able to see what my application saw and correct any potential errors. This was the initial release of Bugfender. But at the time, it had no effect on me; it was merely a solution I discovered to a particular problem I was facing at the time.
I met Stefan shortly thereafter through a mobile app consulting contract. Together, we established the software consulting firm Mobile Jazz. At Mobile Jazz, we assist our clients in developing their ideas and then perform all the necessary specification and design work to transform those ideas into web and mobile applications.
In 2015, the Bugfender concept was reborn within the context of Mobile Jazz. A colleague, Aleix, encountered the same issue while working on a client’s assignment. Our mobile application was interacting with a server outside of our control, and one of our beta evaluators complained that the application did not function for him. However, it worked for us! Since neither his phone nor the server were visible, we were completely in the dark. Again, Aleix devised the same solution: developing a tool to send all data to a server. Aleix was so enthusiastic about the idea that he rushed to put it together over the weekend and proudly presented it to us on Monday.
Wait. I was astonished. Faced with the same issue, we had both arrived at the same resolution. This proved to me that we were on the right track. This must have been something!
How did you construct Bugfender?
Immediately following Aleix’s demonstration, I spoke with him. I recall being ecstatic because I had the same problem and had written the exact same solution four years prior, and I wanted to collaborate with him on it. Additionally, Stefan appreciated it, so the three of us decided to improve it and use it as an internal tool for Mobile Jazz.
It had no moniker at the time because it was merely an experiment. We referred to it as a “remote logger” because it transmits logs remotely.
When Aleix created the very first iteration of the software, the code introduced to the mobile applications consisted of a single class that sent logs to the server. It was in no way a legitimate Software Development Kit (SDK), merely a piece of code that we copied and pasted into the source code of individual applications. The server was utterly incompetent; it simply stored all data sent to it. In total, there were likely no more than 200 lines of code.
The initial version was constructed with Go as an experiment (an experiment within an experiment! ), which stored logs in a MySQL database.
However, even if rudimentary, it was already assisting us! Now, if a consumer encountered a problem, we could create a special version of the application that included this “remote logger” feature. The system would then send us the records so we could see what was occurring. Hooray!
We soon recognized that it would be preferable to include the “remote logger” code in all app builds and enable/disable logging remotely when we detected a device issue. That was our initial evolution.
After that, it continued evolving. Initially, the utility was conceived as a means to provide a better service to Mobile Jazz’s consulting clients, but we soon realized that other app developers were encountering the same impediment. In mobile development, there is always this issue: when a user encounters a problem, it is nearly impossible to reproduce, unlike web and desktop development. In these technologies, it is always possible to verify the server or desktop computer’s records. Contrary to mobile.
Sometimes, mobile applications operate without a server, they may interact with servers that are not under your control, or they may interact with Bluetooth or Wifi-enabled devices, so you cannot predict what is occurring. A further issue is the so-called “device fragmentation”; there are so many various types of mobile phones on the market that you would need thousands of them to adequately test your application. Even with the same configuration and conditions, something that works for you may not function for someone else with a different mobile device.
After five months of internal use of Bugfender, it became evident that we were confronting a universal problem that other companies might be willing to pay to solve. Therefore, we decided to create Bugfender as a product. We created a website and included a “request an invitation” form. In the beginning, there were no fees, and we had to manually access the database and create the accounts. Even a formal registration form was lacking. Due to the small number of individuals requesting access, it was not a tedious task. We attempted to promote our application in developer forums and on Twitter, but received few responses.
However, interacting with actual consumers was beneficial. We began to receive objective feedback, criticism, and feature requests.
It took us approximately four months to add the payment process because we were eager to continue incorporating feedback and enhancing our tool prior to charging. We didn’t give pricing much thought because our initial objective was to determine whether individuals were willing to pay anything. Therefore, we visited a competitor’s website and set up our pricing similarly.
Once the payment system was in place, it took us another six months to acquire our first paying customer. Those were challenging times, but we were full of enthusiasm. When the time came, we held a celebration. A paid user indicated that we were not wholly foolish and that we were creating something that someone wanted, even if it was only 19 euros per month.
Once you begin charging, the situation becomes more serious. Should we incorporate as a business? People started inquiring, “What is our privacy policy?” and we need to provide an answer. Our terms and conditions? Did we encrypt their information? (Obviously, we do.)
In addition, we had numerous misgivings along the way: had we identified the optimal “product-market” fit? It was abundantly apparent to us that money would not magically appear. This was a specialized item. Bugfender addressed a minor annoyance for developers, but we were still unsure if it addressed a significant issue. Could we persuade enough individuals to insert their credit cards?
Incorporating a business, incorporating software metrics to limit functionality based on plan, and integrating a payment and invoicing system… (OMG if you are a person of influence in the European Union and are reading this, calculating the correct VAT for an invoice is ludicrously complicated!!!) Was it worthwhile to exert all of this effort, perhaps without receiving anything in return… ever?
We experienced some ups and downs during the launch process and the subsequent months. Our first paid customer was cause for celebration. Although it was a small sum, it served as validation. When we applied for a grant from the European Union and were chosen out of thousands of applicants, that was an additional moment of excitement. We were awarded 100,000 euros for the development of our product, so we no longer had to develop it with our own money. I recall discussing abandoning ship with the other creators a few weeks prior to that.
Also encouraging us to continue was receiving direct feedback from our users via messaging. The forum had a significant impact on adoption because it allowed us to communicate with potential users and resolve their concerns. We were able to assist our current consumers, which increased retention. It was also a priceless occasion for us to learn firsthand from those who were utilizing the product. This allowed us to create a website that answers genuine user inquiries.
What marketing strategies did you employ to expand your business?
Our growth has been very organic from the start. We were confident in our ability to create the product, but had no marketing experience. The most difficult aspect has been communicating with the appropriate individuals about our product.
After receiving the EU grant, our mentor (hi, Agustn!) insisted that we engage in content marketing. What on earth was that? We had limited knowledge. He assigned us a task: conducting keyword research, for which he provided direction. Then, we selected the top 20 keywords that we believed would have the greatest impact on our development and began working on them. After six months, we aimed to rank on the first page of Google for at least ten of these keywords.
This is simpler said than done; enhancing SEO requires significant effort! The three founding members of Bugfender were engineers. At that time, that was the entirety of our team. Engineers are not particularly fond of writing, but this project necessitated extensive writing. Therefore, it was a double challenge for the engineer. But we persevered and succeeded. Not only did we appear on the first page for the majority of our keyword searches, but we also ranked first for some. This greatly aided our development because, for the first time, we received a substantial quantity of organic traffic.
We also attempted other methods that were unsuccessful. Others advised us to use AdWords, Facebook ads, LinkedIn ads, and Twitter ads. We tested each of these options because they all made logic to us. We invested a substantial quantity of time and money in establishing everything, paying bill after bill, testing, and iterating. Although it worked to attract more visitors, we continued to spend significantly more than we earned in new users and, ultimately, sales. I’d say it was worth a shot, but I’d advise bootstrapped businesses to try other things first and be very frugal with their advertising budgets. When using advertisements, you are competing with large corporations with enormous marketing budgets. I would reserve this strategy for VC-backed businesses with low consumer acquisition barriers, such as complimentary products.
Our experience with Facebook retargeting has been positive. People who have visited our website and expressed interest in Bugfender are shown advertisements. This has been a much more successful strategy, as we are targeting individuals rather than large organizations, who have a much greater likelihood of becoming customers.
We anticipated that our consumers would be so enthusiastic about using Bugfender that they would spread the word. We created an entire referral system with discount codes and invitations, similar to Dropbox’s well-known strategy. We were mistaken; individuals had greater things to do. They enjoyed using our product, but convincing their peers to adopt it was a different matter.
We also attempted to participate in social networks, including Twitter, Facebook, and LinkedIn, but found them to be saturated with marketing messages. Having a meaningful interaction is extremely time-consuming, and in the end, everyone is employing the same strategies, making it extremely challenging to separate out from the throng. We’ve recently discovered that being more active on Twitter has benefited us, likely because developers congregate there more, so we’re increasing our efforts there while decreasing our activity on other networks.
We also utilized A/B testing to enhance the content of our website. Even if it sounds fine in principle, you need tens of thousands of visitors to your website to obtain meaningful results. And often these tests are inconclusive because there is little difference between the items you tested, or because the effect on your conversion rate is so negligible that it does not matter, so we have found them to be of limited utility in our case.
So far, we have determined that content marketing is our hobby, and we continue to work on it. But we have not ceased attempting new things, and we will continue to do so; we will likely never stop, given that times and businesses change. Perhaps some of the things we have attempted in the past will succeed in the future.
What were the greatest obstacles you confronted and how did you overcome them?
I have already described a few of the emotional highs and lows. The paucity of financial resources has been the greatest obstacle to date. Everything is managed with our own time and funds, which has become increasingly difficult. During difficult circumstances, you may begin to question whether it is worthwhile to continue. The investment is yielding a sluggish return, but it is working!
We are currently in a quasi-profitable position, which allows us to cover our expenses but not pay ourselves a salary. Still, we do not need to continue contributing money, which is a plus, but we must work for free. I hope that we attain the so-called “ramen profitability” as soon as possible, at which point we will be paid something, even if it is only a small amount, which may not make a huge difference but will certainly help raise our spirits.
We have currently surmounted this limitation by dividing our time between Bugfender and Mobile Jazz consulting. It is not optimal, but it is functioning despite extreme difficulty.
What are your most significant disadvantages?
It is difficult to discuss disadvantages for two reasons: first, we do not want to see them, and second, many advantages and disadvantages are, in my opinion, two aspects of the same coin. Therefore, they define you but do not determine your destiny. Let me explain:
One could argue that bootstrapping is a vulnerability, for instance. Nonetheless, I believe it will be an advantage if we are able to make the company profitable, which is highly likely. The lack of copious resources has made us wise (or helped us “stay hungry,” as Steve Jobs would say), and we are able to operate our business with a small monthly income. Therefore, being bootstrapped has made us parsimonious, which is a good thing. Unfortunately, it is all too common for businesses to fail because they exhausted their resources.
In addition to this, Bugfender is a paid product. There is a complimentary version available for experimentation, but the “good stuff” is reserved for paying customers. Again, this is a vulnerability, because if Google/Facebook/Twitter release a free version of a similar product to Bugfender tomorrow, we may have a difficult time competing. Again, the disadvantage is readily apparent, but what is the benefit? If you are not paying for something, you are not the consumer; you are the product being sold. We have a distinct understanding of who our consumers are and protect their privacy. There is no gratis product that can provide this.
I also stated that our target market consists of mobile developers. This fundamentally implies that we operate in an ecosystem governed by Apple and Google. There is definitely a lot of money to be made, but the risk of relying on these two companies is not insignificant. This is true for anyone working on an app or a product for applications, in my opinion. The only solution is to remain cognizant of this risk and diversify as soon as feasible.
In the process of constructing and expanding Bugfender, what were the worst errors you made?
Personally, I am aware that I am too pessimistic. Since I could harm the team’s morale, I must be careful with how I phrase things and how I communicate my emotions to them. Fortunately, I teamed up with the proper individuals, and we rely on each other’s support when things go awry. It has been successful thus far.
I mentioned that the entire Bugfender team also works on Mobile Jazz for primarily economic considerations. We could have possibly made the decision to hire an external, full-time Bugfender employee earlier. I believe that multitasking has caused us to neglect some excellent opportunities.
Also, I believe we have not yet experimented with pricing enough as a company. Our pricing is founded on certain assumptions, but we have not conducted extensive testing. For instance, we currently offer a free plan that we believe encourages individuals to try Bugfender without concern. However, how would substituting a trial for the free plan work? We do not know.
On the technology front, we have also committed errors. Working in Go initially seemed appealing because we were anxious to learn new technologies, but Go was immature at the time, and we have paid the price. In addition, we continue to struggle to locate qualified developers.
The selection of libraries was the source of problems. We selected martini as the web framework, but its performance was so inadequate that even its author moved on to a new project called gin. Migrating from Martini to the native HTTP library has resulted in a 10x improvement in performance, saving us literally tens of thousands of dollars per month. We accessed the database using gorm (version 1). In addition, gorm was substantially rewritten in the subsequent months, resulting in an incompatible API with the version we use; this primarily necessitates rewriting our code and performing a thorough data migration… we will likely abandon gorm in favor of sqlx, a widely-used library that gives us greater control over performance. I suppose this is a reflection of the language’s evolution as the development community matures.
We compiled a list of pros and cons in a blog post about Go and the selection of libraries, with the hope that it will assist others in making better decisions in the future.
Moreover, we were compelled to evolve the primitive MySQL-based system. Relational databases are inadequate for write-intensive tasks such as record storage. Redis is used to cache the most frequently accessed data while Kafka and Elasticsearch are used to store records.
If you had the opportunity to do things differently, what would you do differently?
I would employ a marketing professional immediately. We grossly underestimated the quantity of effort required for marketing. We believed that a few advertisements and a few blog posts would be sufficient to let people know about us. If I could go back in time, I would search for someone working in marketing in our industry and employ them as soon as money allowed.
After some time has passed, everything becomes more distinct. Obviously, if we had known that placing advertisements was ineffective, we would have spent much less time and money attempting to implement them. The process of identifying the optimal marketing strategy has been particularly time-consuming, but it is necessary.
I wish I had spent more time conversing with prospective clients. After three years in business, I still encounter individuals who do not “get” what we do. This does not imply that they are stupid; rather, it indicates that I cannot adequately articulate the situation (making me the idiot). I attempt to communicate extensively with customers and potential consumers, but I believe more time would have yielded superior results.
Before launching Bugfender, we also tested out a competing product. It was titled “PlayThis” and it was a collaborative playlist for selecting celebration music. We intended to make it free or inexpensive for private functions (such as at home) and sell it to establishments. We spent several months developing the product before releasing a version to the app store. Do you know who frequented the establishments at this time? Nobody! Do you know how many copies of the software we sold? None, ever. This taught us a valuable lesson: we must communicate with consumers prior to constructing anything.
Because I am aware of the steep learning curve and prevalence of this error among entrepreneurs, I want to emphasize: do not write a single line of code until you have a paying customer.
Even better is if you can get someone to pay upfront (or at least pledge to purchasing). In addition to financing your project, this will ensure that it contains the necessary components and offers a solution (at least to one individual).
And the opposite is also true: it does not matter how impressive your technology or idea is. If nobody is aware of it, nobody will purchase it. Once you speak with your first prospective customers, you will realize that they may require something entirely different from what you had in mind, or that what you believed to be an untapped market opportunity, nobody cares about.
On the technology side, I would have started with a well-known technology platform. It would not have been as enjoyable, but it would have accelerated the endeavor and saved us money. Due to subpar software performance, we have had to upgrade our infrastructure for some time now, which costs us thousands of dollars per month. In addition, we have a peculiar burden, as we generate terabytes of logs every month and must make them readily accessible to users who wish to review them. Even more so if you’re unfamiliar or inexperienced with the technology stack, striking a balance between these optimizations is difficult.
In addition to errors, what other learning resources would you recommend for aspiring entrepreneurs?
Not everyone enjoys the same forms of media, so I will recommend a variety of my personal favorites. Since I enjoy reading, I would suggest The Mom Test. It is a brief and sweet book that benefited me tremendously in the “talking to customers” department. I believe that every entrepreneur should read it before undertaking any endeavor.
Additionally, the Start Small, Stay Small book, The Lean Startup book, and the Signal vs. Noise blog discuss bootstrapping, i.e. constructing a project with your own time and money and without or with minimal investor assistance. Now, not every project can be constructed in this manner, but many people are unfamiliar with this alternative to venture capital funding, so I would recommend learning more about it and determining which method is most suitable for your idea.
I appreciate the Smart Passive Income podcast for its concepts, the majority of which are bootstrapped. This format gives me a great deal of vitality. The Rework podcast is a wonderful compilation of entrepreneurial tales from a variety of entrepreneurs. I frequent the forums of both Indie Hackers and Hacker News.
I also had to learn a great deal about marketing, as I entered the workforce knowing nothing about it. I routinely listen to Neil Patel’s podcast, blog, and newsletter, and I adored his book Traction: A Startup’s Guide to Acquiring Customers.
For further information
You should absolutely visit the Bugfender website. To learn more about our voyage, please refer to Three Years of Bugfender: 9.5 Million Users, a retrospective we wrote on our third anniversary, and Four Lessons Learned From Bootstrapping Products, a collection of reflections on our lessons.
My co-founder Stefan Klumpp was also featured in an interview with Indie Hackers a year ago, where you can learn more about our early phases, financing, and road map.
If you would like to contact me, my Twitter handles are @bugfenderapp and @gimix3.
Main pic is from bugfender.com
We gather unique business case studies from all over the internet, to inspire you with a wide range of business ideas. This case study was supervised by our team and it definitely caught our interest. You can find other inspiring business stories here.
English 
German 
Spanish 