Bugfender

Cloud Storage for Your App Logs

10+ Employees
Multiple Founders
Founders Code
B2B
Productivity
Programming
SaaS
Utilities
July 18, 2023 API access learnings

We recently updated our API, and I wanted to share a couple of things in case you want to build a public API too.

A few years ago we decided Bugfender users could use an API to access the logs they capturing with our tool. We thought some people would build utilities to support their daily work, like integrations with other tools, data mining, or analytics. Some people could even make those tools public, as add-ons to Bugfender.

Building the API was fairly straightforward because we had made the decision to build Bugfender with the Single Page Application architecture early on, which meant there was already a working API, only it was being used exclusively by our frontend. We could reuse that.

However, when you make an API public there are some additional things to take into account:

  • Authentication and authorization: you need to identify your users and applications, and decide which permissions each will have. It's likely your application already has a permission system, but now adding applications into the mix you might need to review it. We chose OAuth 2.0 because it fit well with our application model and the usage we were expecting of the API (but we learned something, see later!).
  • Rate limits: opening the API will likely cause additional work for your backend. Are you prepared for that? Plan ahead and set limits to prevent accidental or intentional overload of your servers. We decided to use the draft-ietf-httpapi-ratelimit-headers RFC draft for that, because there are many options out there, all different, so we chose to go with a standard one (or at least we feel has the potential).
  • Documentation: you need to describe your endpoints and provide examples for your users to know how to use your API. We chose OpenAPI (formerly known as Swagger) to describe the endpoints, which lets you automatically generate an API documentation portal, can be used to autogenerate code for many programming languages, and integrates with tools like Postman.

The theory

When we launched the API, we were expecting people would build their own tools on top of Bugfender for data mining, integrations with 3rd party platforms, and whatnot.

Therefore, we built an API access model based on "apps" that connect to Bugfender. Some apps would be for personal use, some for use within a specific organization or team, and some would be public for use by any Bugfender user.

This is also why we chose OAuth 2.0, because it's specifically built for this use case.

The reality

When we launched API access, we purposefully didn't build a UI for it. We asked people to contact us if they wanted to use it.

In hindsight, that was a great decision because we can learn how people want to use the API and we can provide them with pointers on how to get started. We also can find opportunities for improvement both in the API and the documentation.

So, the most common OAuth 2.0 use cases work like this, and this is what we built:

  • A developer creates an "app" that works for any Bugfender user (OAuth 2.0 calls this a "client")
  • A Bugfender user installs this "app" on their account and authorizes it
  • Now the "app" has access to the user's data on Bugfender

However, most of the users requesting API access were not interested in building an "app". They just wanted to access their own logs and make queries or export them to another service. So they were expecting a flow like this:

  • They request an access token
  • They use that access token in their app
  • FIN

After a bit of investigation, personal access tokens were not what they were looking for, either, because they might not want the application to have unlimited access to their account.

The learning

The piece in the puzzle we were missing were "service accounts". Service accounts represent an application in Bugfender, have their own credentials to access it, and can be given permissions like any other user.

Luckily, OAuth 2.0 client credentials grant is exactly for this use case! So we could easily adapt to this use case. Happy ending.

In summary

  • Think how your users will want to use your application (theory)
  • Once you build it, talk to your users and double-check that what you built is what they needed (reality)
  • Learn and iterate
June 20, 2022 ISO 27001 certification

As a tiny bootstrapped company, it was a long road from reading up all we could find about ISO 27001, to drawing out all the documentation and processes required, to finally getting certified. It's been almost two years, but even as a small company, you can do it!

Here is how we did it and how I would recommend doing it:

  • Read all we could find about it on the internet. There are many good articles to help you understand which are the steps and how much work it's actually involved. Spoiler alert: a lot!
  • Read the ISO 27001 and ISO 27002 standard documents all the way, to make sure this is actually what you want to do.
  • Purchase a set of template documents that will help you get started writing. - Documentation is a big part of the process, and getting some scaffolding was a great way to avoid writer's block and make sure we didn't miss anything important.
  • Lay out a plan and execute it. This is actually part of the ISO 27001 implementation itself: make a list of all the things you need to do and cross them, one at a time. The list might seem very long, but do not shy away. It took us a bit longer than one year, but we got it all done.
  • Hire an external auditor to get your certificate.
  • Rinse and repeat: keep running the processes, and improve them over time, in order to keep the certification.

Some benefits we experienced by implementing ISO 27001 in Bugfender:

  • Increased uptime: in the last two years, we have only experienced a major outage of 5 hours, with no data loss.
  • Better team coordination: better processes means everyone knows what to do and when. This is an immediate benefit every day, but is especially important during a crisis.
  • Increased trust from clients: especially, some corporate clients will only purchase from certified ISO 27001 or SOC 2 vendors.
December 10, 2021 ISO 27001 and HIPAA compliance

In the last few months, we have been getting increasing attention from larger companies, and with it, questions about security and compliance. Whilst we have always been very proactive and transparent with our security practices, we have never been doing it formally. So we looked into ISO 27001 as a way to provide reassurance to our customers that their data is secure with us. A few months ago we passed our first audit and we're now preparing for a second one.
In the meantime, we have also had questions about HIPAA, and once ISO 27001 was in place, it was actually pretty easy to get it done. So, 2 for the price of 1! We're now both ISO 27001 and HIPAA compliant.

July 7, 2020 Bugfender now offers a web SDK

We have been offering logging for mobile applications for 6 years now, and we have always known web applications could benefit from the same technology, but we have been dragging our feet forever. We finally did it!

We accomplished this by treating it as a separate mini-project within the company, with a team exclusively devoted to it, with its own budget and calendar and it has worked very well so far. We will be applying this technique more often.

July 7, 2020 Bugfender now offers a web SDK

We have been offering logging for mobile applications for 6 years now, and we have always known web applications could benefit from the same technology, but we have been dragging our feet forever. We finally did it!

We accomplished this by treating it as a separate mini-project within the company, with a team exclusively devoted to it, with its own budget and calendar and it has worked very well so far. We will be applying this technique more often.

November 13, 2019 From side-project to sustainable $20k/mo business

It’s nearly five years since we started Bugfender. 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.

To celebrate the $20k Monthly Recurring Revenue milestone and reaching profitability, we wrote an article with our learning and experiences. We hope you like it!

https://bugfender.com/blog/bugfender-growth-from-side-project-to-a-sustainable-20k-mrr-business/