Hi Jordi! What's your background, and what are you currently working on?

Hi there! My name is Jordi Giménez. Once upon a time, I studied computer science in Barcelona which led to jobs in web back-end, web front-end, IT security, and more. More recently, my path has led me to iOS and Android development. I love Barcelona, and I’ve been lucky enough to co-found two companies there, Mobile Jazz and Bugfender.

Besides Mobile Jazz and Bugfender, we also run experiments such as Localname, a service to give your local development machine a URL accessible from the Internet and DevCraft, a newsletter for the curious developer. We are testing both and they might or might not become “something” eventually.

Bugfender is a tool to help developers debug their mobile applications by collecting the logs of their user’s mobile devices from anywhere in the globe. We get the logs and put them together in a clean interface, where you can filter and view data by user, time frame, mobile device make and model and similar things. Some readers might be familiar with crash reporting tools; Bugfender goes one step further by allowing remote access to the logging facilities of users’ devices. 

We started the company with only 3 employees, but today we are a team of 9. Bugfender today is installed on more than 9000 apps and running on over 46 million devices. We went from zero to $11,000 monthly recurring revenue (MRR) in 4 years, without any external investment.

I do 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, to writing content for our blog. Every day is a little different.

As you can see, everything we do is bootstrapped. As founders, we are the only investors; our investment is our time, not a ton of cash. This impacts how we run the company: After four years our team is only 9 people, some of them part-time, and we are very careful with our budgets. For example, when setting up an advertisement campaign, our goal is to make a useful product people are willing to pay for. Our ads are sometimes a little confounding to potential customers because nowadays so many things are “free” in the sense they cost no money. But even with these “free” SaaS products, consumers need to know that are still paying in some hidden way, like being targeted with advertisement and having your data sold to the highest bidder.

In contrast, we are looking for straightforward customers who value what we offer and are willing to pay for it. Fortunately, there are enough of these people that we are about to reach break-even. We could have already reached break-even if we stopped investing in the company, but we are choosing to keep investing above our revenue, even if this slightly affects our financials for now. We are very open with our numbers, you can check them real-time here.

Another fun fact is that the company is totally remote. I am based in Barcelona, but our team is distributed all around Europe. We work remotely and plan retreats or “workations” every now and then. Early on we recognized that meeting together face to face is essential to productivity and team building. Plus, it’s just really fun.

‍

What's your backstory and how did you come up with the idea?

I personally started mobile development in 2011. Back then, I was developing my very first mobile application for Android: an app to check the balance of my prepaid SIM card. It was an experiment for me, and I just wanted to learn about Android. My mobile phone operator didn’t have an app and I was annoyed that I had to keep checking their website to make sure my credit didn’t run out.

So, I made an app that used “web scraping” to get my balance from the website. (Web scraping makes use of an application to log into a web browser like a real user, click the appropriate buttons to get to the screen with the information you want, and then extract or “scrape” the information for your use.)

It worked great for me. Since the operator didn’t have an app, I decided to make it public, in case it was useful to someone else. It turns out it was. Within a few months, it garnered more than 20,000 users, which was a high percentage of the customers that operator had back then.

But the problem with web scraping is that unlike humans, applications can get thrown off by routine changes in the phrasing or structure of the information shown. For example, back then my application was being used by both prepaid and contract users, so the website looked slightly different for each kind of user depending on the product—different enough to break my application.

To solve this, I decided to make a little web service that my application could send the data to if it turned the content was not what it expected. This way I could see what my application was seeing and fix the potential errors. This was the very first version of Bugfender. But back then it didn’t make any impact on me, it was just a solution I found to a specific problem I was dealing with at the moment.

Shortly after that, I met Stefan in a mobile app consulting gig. Together we founded Mobile Jazz, a software consulting agency. At Mobile Jazz, we help our clients work on their ideas and then do all the legwork of specification and design to turn ideas into living web and mobile applications. 

Within the context of Mobile Jazz, the idea of Bugfender was reborn in 2015. While working on a client’s project, a colleague, Aleix, had the same problem again. He had a situation where our mobile application was interacting with a server outside of our control and one of our beta testers was complaining the application didn’t work for him. But it worked for us! Since we could not see his phone nor the server, we were left totally in the dark. And again, Aleix came up with the same solution: building a tool to send all the logs to a server. Aleix was so excited with the idea, he hacked it together in a rush over that weekend and proudly showed it to us the next Monday.

‍

Wait. I was shocked. Faced with the same problem, we both had come up with the same solution. This confirmed to me that we were on to something. This had to be something!

‍

How did you build Bugfender?

Immediately after seeing Aleix’s demo, I talked to him. I remember I was super excited because I had the same problem and wrote the exact same solution 4 years earlier and I wanted to work with him on it. Stefan also liked it, so we agreed the three of us would build a better version and use it as an internal tool for Mobile Jazz.

Back then it didn’t even have a name yet, it was just an experiment. We called it “remote logger” because it sends the logs remotely.

When Aleix built the very first version, the code added to the mobile applications was a single class we hacked together that sent logs to the server. It was not a proper Software Development Kit (SDK) in any way, just a piece of code that we would copy-paste into the code of individual projects. The server was completely dumb—it just stored anything that was sent to it. Overall, it was probably no more than 200 lines of code. 

The first version we built with Go as an experiment (an experiment within an experiment!) which would write the logs in a MySQL database.

But, even if crude, it was helping us already! Now if a customer had a problem, we could make a special build of the application with this “remote logger” thing built in. Then it would send the logs over and we could see what was going on. Hooray!

We quickly realized it would be better to include the “remote logger” code in all builds of the app and just enable/disable logging remotely when we knew there was a problem with a device. That was the first evolution we did.

After that, it kept evolving. Initially, the tool was only born as a way to provide a better service to our consulting clients at Mobile Jazz, but soon enough we saw other app makers were running into the same roadblock. In mobile development, there is always this problem: when a user is experiencing an issue, it’s almost impossible to reproduce, unlike web or desktop. In those technologies, you can always resort to checking the logs on the server or the desktop computer. Not so with mobile. 

In mobile, sometimes applications operate without a server, maybe they interact with servers not under your control, or maybe they interact with Bluetooth or Wifi-enabled devices, so you have no way to know what could be happening. Also, yet another problem is the so-called “device fragmentation.” There are so many different mobile phones on the market that you would literally need thousands of them to test your application properly. Even with the exact same setup and conditions, maybe something working for you does not work for someone with a different mobile phone.

After 5 months of using Bugfender internally, it was clear to us we were facing a universal problem other companies might be willing to pay for. So, we set out to build Bugfender as a product. First off, we made a website and added a “request an invitation” form to it. In the beginning, we did not charge anything and we had to manually go to the database and create the accounts by hand. We didn’t even have a proper registration form. It was not an annoying task because very few people were requesting access. We tried promoting our tool in developer forums and Twitter, but we got very few responses.

However, working with real users helped us. We started receiving the first unbiased feedback, criticism, and feature requests.

It took us about 4 months to add in the payment process because we were happy to keep incorporating feedback and make our tool better before starting to charge. We didn’t give much thought to pricing because our goal was to initially find if people were willing to pay something, regardless of how much. So, we went to a competitor’s site and set up our pricing in a similar way.

Once we had the payment process ready, it still took us another 6 months to get our first paid user. Those times were a little hard, but we were full of enthusiasm. When the moment arrived, we celebrated. A paid user meant we were not completely stupid, we were building something someone wanted, even if they only paid 19€/month.

Once you start charging, things start to get more serious. Shall we incorporate as a company? People started asking questions we need to answer: What is our privacy policy? Our terms of service? Did we encrypt their data? (Of course, we do.)

Also, we had lots of doubts along the way: had we found the right “product-market” fit? It was pretty clear to us that money wasn’t just going to pour in. This was a niche product. It really did “scratch an itch” for developers, but we still wondered if Bugfender really addressed a major pain point or not. Could we convince enough people to reach for their credit card and put it in?

Incorporating a company, adding metrics in the software to limit the functionality depending on plans, adding the payment and billing process... (OMG if you are someone with influence in the European Union and are reading this, calculating the right VAT for an invoice is ridiculously complex!!!) Did it make sense to put in all this effort, perhaps without getting anything in return... ever?

We had some ups and downs in the launching process and in the following months. Getting our first paid user was a moment of celebration. Though it was little money, it provided validation. Another exciting moment was when we applied for an EU grant and were selected from hundreds of applicants. We were awarded 100.000€ for developing our product, meaning we would no longer need to develop out of our own pocket money. I remember I was talking with the other founders about abandoning ship a mere few weeks before that.

Something which also encouraged us to keep going was getting direct feedback from our users via chat. The chat had a great impact on adoption because we could talk to potential users and address their concerns. We could help our existing users which increased retention. It was also an invaluable opportunity for us because we could learn directly from the people who were using the product. This helped us build a website that addresses actual user questions.

Which were your marketing strategies to grow your business?

Our growth has been very organic since the beginning. We knew we could build the product no problem, but we had zero knowledge about marketing. The toughest part has been to reach the right people to let them know about our product.

After taking the EU grant we had a mentor (hello Agustín!) who insisted we had to do content marketing. What the heck was that? We did not know much. He had us do an exercise: He asked us to do some keyword research and he provided some guidance. Then we chose the top 20 keywords we thought would have the biggest impact on our growth and we set ourselves to work on those. Our goal was to appear on the first page on Google after 6 months for at least 10 of those keywords.

This is easier said than done—improving SEO takes a lot of work! The three founders of Bugfender happened to be engineers. At that moment, that was our entire team. Engineers aren’t super into writing, and this required writing, lots of it. So, it proved a doubly challenging feat for an engineer. But we set to it and we made it. We not only appeared on the first page in many of our keyword searches, but we made it to first place for some. This helped our growth a great deal because for the first time we had a significant amount of organic traffic coming to our site.

We also tried other things that did not work. We had other mentors recommending AdWords, Facebook ads, LinkedIn ads, Twitter ads. All of these options made sense to us, so we tried them out. We spent a significant amount of time and money setting everything up and paying bill after bill, testing and pivoting. Though it worked that we got more visitors, we were still spending much more than we made back in new users and, ultimately, purchases. I would say it was worth trying but I would recommend bootstrapped companies try other things first and be very conservative with ad spending. When using ads, you are competing against big companies with huge marketing budgets. I would reserve this strategy for VC-backed companies with a low-barrier for customer acquisition, like free products.

We have had a good experience with Facebook retargeting. We show ads to people who have expressed some interest in Bugfender by visiting our website at some point. This has been a much more successful strategy, since we are targeting individuals, instead of big groups, with a much higher chance to turn them into customers.

We also thought our customers would be so excited to use Bugfender that they would share it. We built a whole referral system with promo codes and invitations, similar to the strategy Dropbox uses and is well known for. We were wrong, people had better things to do. They were happy using our product but talking their friends into using it was a different thing.

We also tried participating in social networks: Twitter, Facebook, and LinkedIn, but we found they are already too full of marketing messages. Having a meaningful interaction is extremely time-consuming and in the end, everyone is trying the same tricks, so it is very difficult to stand out in the crowd. We have recently found, though, being more active on Twitter helped us, probably because developers hang out more on Twitter, so we are doubling our efforts there while reducing the activity in other networks.

We also tried A/B testing for improving our website content. Even if in theory it sounds good, you need many thousands of visitors to your website in order to extract meaningful results. And often those tests are inconclusive just because there is not much difference between the things you tried, or the impact in your conversion rate is so tiny it does not matter, so we have found them not very useful for our case 

So, for now, we know content marketing is our hobby horse and we keep working on it. But we have not stopped trying new things and we will keep trying; we will never stop, probably, since times change and companies change. Maybe some things we tried in the past might eventually work in the future.

‍

What were the biggest challenges you faced and obstacles you overcame?

I already mentioned some of the emotional ups and downs. The biggest challenge so far has been the lack of money. We run everything with our own time and money, and this has become increasingly difficult. During the low times, you can really start to ask yourself, is it worth it to keep going? We’re about to break even, so the investment is paying off slowly—but it is working! 

We are now in a kind-of profitable situation, which means that we can pay our expenses, but we cannot afford to pay a salary to ourselves. Still, we do not need to keep putting money in, which is good, but we have to work for free. I hope soon enough we reach the so-called “ramen profitability”, where we can get paid something, even if a little bit, that might not make a big difference but for sure will help in lifting our spirits.

We have overcome this limitation for now by splitting our time between Bugfender and consultancy work (for Mobile Jazz). It is not ideal but it is working, though it has been extremely difficult.

Which are your greatest disadvantages?

Good question :) It’s very difficult to talk about disadvantages, first because we do not want to see them, second because in my opinion many advantages and disadvantages are two sides of the same coin. So, they define you but they do not determine your fate. Let me explain:

It could be argued that being bootstrapped is a weakness, for example. Yet I still think it’s an advantage if we can make the company profitable—and by all odds, we are going to. The lack of abundant resources has made us wise (or helped us “stay hungry” as Steve Jobs would say), and we are capable of running the company with little income each month. So being bootstrapped has made us frugal and that is a great thing! We are unfortunately too used to seeing companies go under because they burnt through all of their funds.

Another trait defining Bugfender is it is a paid product. We have a free version for testing, but the “good stuff” is only for paying customers. Again, this is a weakness, because if tomorrow a Google/Facebook/Twitter comes and makes a free version of something similar to Bugfender… we may have a hard time. Again, the disadvantage is very clear, but what’s the advantage? You know the saying “If you are not paying for it, you're not the customer; you're the product being sold”? We have a clear understanding of who our customers are and we provide privacy to them. That is something no free product can provide.

Also, I mentioned our target market are mobile developers. This means essentially, we work in an ecosystem controlled by Apple and Google. There is certainly a lot of money in it, but the risk of depending on the rule of these two companies is not marginal. I would say this is true for anyone working on an app or on a product for apps. The only solution to this is to keep this risk in mind and diversify as soon as possible.

‍

During the process of building & growing Bugfender, which were the worst mistakes you committed?

On a personal level, I know I am too pessimistic. I have to be careful how I phrase things or how I express my feelings with the team since I could damage their morale. Fortunately, I happened to team up with the right people and we rely on each other’s support when things go out of balance. It has worked very well so far.

As a team, I mentioned everyone who works on Bugfender also works on Mobile Jazz, mainly for economic reasons. We maybe could have made the decision to hire someone completely external earlier, who would work full-time on Bugfender. I think the multi-tasking has made us miss some good opportunities. 

Also, as a company, I think we have not experimented enough with pricing just yet. We have a pricing based on certain assumptions but we have not tested much. For example, right now we have a free plan which we believe helps people try Bugfender without fear. However, how would changing the free plan for a trial work? We do not know.

On the technology side, we have also made mistakes. Working in Go seemed very appealing in the beginning since we were eager to learn about new technologies but Go at that moment was not mature and we have paid the price for it. Also, today we are still finding it difficult to find experienced developers.

Something causing problems was the choice of libraries. We chose martini as the web framework and it resulted to be extremely poor performance; even its author moved on to a new project called gin. Migrating away from martini to the native HTTP library has improved the performance about 10x for us, saving us (or in the previous months costing us) thousands of dollars, literally. For database access, we used gorm (version 1). But also gorm was mostly rewritten in the following months, resulting in an incompatible API from the version we use; it mainly means we should rewrite our code and do a thorough data migration… we are probably going to leave gorm and stick to sqlx, which is a widely used library giving us better control on performance. I guess this is all a reflection of the evolution in the language as the development community matures.

We wrote a blog post about Go and the choice of libraries, listing all the pros and cons—maybe it could help other people make better choices next time. 

Also, we naturally have had to evolve the primitive MySQL based system. Relational databases are not good at write-heavy workloads such as log storage. We have evolved it into a more complex setup with MySQL only for certain data, then using Kafka and Elasticsearch primarily for storing logs, with some help of Redis for caching the most commonly accessed data.

If you had the chance to do things differently, what would you change?

I would hire a marketing person right from the start. We completely underestimated the amount of effort our marketing would require. We thought a couple of ads and a couple of blog posts would be enough to let people know about us. If I had the chance to go back, I would look for someone working on marketing in our space and hire them right away, as soon as money permitted.

After some time passes, you can see everything more clearly. Of course, if we knew placing ads didn’t work, we would have spent much less time and money trying to set them up. Finding the right marketing strategy has been particularly time-consuming, but it is a process you need to go through.

I wish I spent more time talking to potential customers. After 3 years of operation, I still find people who do not “get” what we do. This does not mean they are dumb, it means I cannot explain it properly (so I am the dumb one). I try to talk a lot with customers and potential customers, but I still think more time would have led to better results.

Before starting Bugfender, we also tried another product. It was called “PlayThis” and it was a collaborative playlist to choose the music you play in a party. We had the business plan to make it free or cheap for private parties (e.g. at home) and sell it to bars. We built the product for a few months until we had a working version on the app store. Do you know who went visit the bars during this time? Nobody! Do you know how many copies we sold of the software? None, ever. This taught us a valuable lesson: we need to talk to the customers before building anything.

Because I know it is a big learning curve and a common mistake among founders, I want to emphasize: do not write a single line of code until you have someone willing to pay for it.

It’s even better if you can get someone to pay in advance (or at least commit to buying). Besides funding your project, this will guarantee it has the necessary bits and pieces and provides a solution (at least to one person).

And the contrary is true: it does not matter how amazing your technology or good your idea is. If nobody knows about it, nobody will buy it. Once you talk to your first potential customers, you will realize they might need something completely different from what you had in mind, or what you thought was an unexplored market opportunity, turns out nobody cares.

On the technology side, I would have chosen a well-known technology stack from the beginning. It would not have been as much fun, but it would have helped to speed up the project and we would have saved money. We have had to beef up our hardware for a while now because of poorly performing software and that cost us thousands of dollars every month. Also, we are handling a peculiar workload, since we write terabytes of logs every month but at the same time, we have to make them easily available for when a user wants to check them. Striking a good balance in these optimizations is complex, let alone if you are not very comfortable or experienced with the tech stack.

‍

Apart from mistakes, what are other sources of learning you would recommend for entrepreneurs who are just starting?

Not everyone likes the same media, so I will recommend several things that worked for me. I love reading, so I would recommend The Mom Test. It is a short and sweet book which helped me a lot in the “talking to customers” department. I think every entrepreneur should read it before starting anything.

Also, the Start Small, Stay Small book, The Lean Startup book and the Signal v. Noise blog talk about bootstrapping i.e. building the project with your own time and money and seeking no or very little help from investors. Now, not every project can be built this way, but a lot of people do not know much about this alternative to VC funding, so I would recommend learning a bit about it and seeing what is most suitable to your idea.

I like the Smart Passive Income podcast in order to get ideas, most of them bootstrapped too. It is a format that gives me a lot of energy. The Rework podcast is a nice collection of stories from different entrepreneurs to learn a lot about entrepreneurship. I also regularly hangout in the Indie Hackers and Hacker News forums.

On marketing, I also had to learn a lot because I had zero knowledge about this when I started. I loved the Traction: A Startup Guide to Getting Customers book and I regularly listen to Neil Patel’s podcast (he has a blog and newsletter too).

Where can we go to learn more?

You should definitely check Bugfender’s website. To learn more about our journey, you can check Three Years of Bugfender: 9.5M Users, a recap we did on our third anniversary, and Four Lessons Learned From Bootstrapping Products, some reflections on our learnings.

My co-founder Stefan Klumpp was also interviewed in Indie Hackers half a year ago, where you can learn more details on our early stages, funding and roadmap.

If you want to contact me, I’m available on Twitter at @bugfenderapp and @gimix3.