In today’s episode, let’s talk about Sentry’s origin, the early days iteration, and how we eventually started the business. If you have a side project you enjoy hacking on, or maybe you’re in the early stages of product-market-fit, this might be for you.

Sentry starts long before Sentry, with a once known project aptly named django-db-log. Somewhere circa early 2008, on a long since forgotten chat medium called IRC. There was a small group of individuals - passionate individuals like Simon Willison - who used to hang out in a channel called #django-users, and I was one of them. An anonymous user asked a simple question: how would you record errors to a dashboard? I obliged them with some example code, created a repository out of it, and the project was born. It’s not an overly interesting origin story, and its not filled with hardships, but its the truth.

Over the years I worked on a lot of open source. I genuinely enjoy building things, and Django was the community that really drew me in. I was fortunate enough that no one cared about open source so I could open source just about anything I worked on, whether it was from my side projects or random utilities I built at work. Over those early years, I open sourced dozens of small projects, many being extensions to the Django web framework: django-devserver, django-sphinx, and django-uuidfield for example. Of course django-db-log makes that list, but it focused on a passion I didn’t recognize at the time. That passion was solving my own problems- making my own work less tedious, my own day-to-day less frustrating. That passion, and that yearn for community, that more than anything else is what I contribute to both my personal success, as well as the success of our now business.

Eventually projects like django-db-log led to career opportunities. I have a vivid memory of going into an interview at Disqus (a startup I joined in 2010), watching them install the dependencies, and seeing several with my name on them. I had already interviewed and passed the assessment before I even talked to the team, and that’s a big deal for me given I am self-taught, come from rural America, and generally speaking have not had access to a lot of opportunities outside of ones I’ve created. That moment, and several other similar stories, are why I’ve been such a long believer in the power of Open Source for an individual’s career. As alluded, I joined Disqus, my first experience working at a “real” startup.

Disqus was an interesting learning ground for me. Going in I was ambitious and productive, but you don’t know what you don’t know, and at that age there was a lot I didn’t know. It’s the era where I learned (and eventually preached) the value of testing. It’s when I met many of my former colleagues who have become lifelong friends, some of whom still work at Sentry. Most importantly, it’s the era that allowed me to significantly expand my career options, both by investing time into projects like django-db-log, as well as speaking at various Python conferences. Disqus was also an enabler to my open source contributions, and importantly they relied on django-db-log. That meant that at various times I had a financially motivated reason to invest more time into it. As an example, in the early days (in fact, this might have been my first week on the job) I took down the entire platform. I don’t recall why, but I do recall it being extra painful due to django-db-log’s inability to scale. It couldn’t handle the huge volume of errors I had just thrown at it, and based on how little email we could receive over the next day, nor could gmail handle the amount of alerts that it generated.

If I had to pick the single most important event for Sentry, it would be this real-world use of the project at my full-time job. It meant investment in the project was based on practicalities, based on what we actually needed it to do at the organization. It meant that investments being made into the project were being made for myself to improve my own day-to-day as well as those of my team. I worked at Disqus from mid 2010 to early 2013, a little under three years. It was in that time that we decided to rename the project (first to django-sentry and eventually to Sentry). It was also at that time that we decided to bootstrap the company.

I don’t recall exactly when we started development on the cloud services for Sentry, but I do recall being thoroughly uninformed about what it’d take to launch a software-as-a-service company. You see, I had been pitched the idea of launching an AddOn on Heroku by one of the at-the-time PMs. It seemed like an easy concept: make Sentry easy to run on Heroku and make a few bucks. The ambitions were high at the time: “beer money” specifically is how I remember thinking about our potential success. When I kicked this off I recruited Chris Jennings (aka ckj) to help me start the company. He had already helped out on the project at Disqus so he was familiar with the project. I recall it being close to the end of the 2012, around Christmas, where things slow down at work. Chris and I decided to use our holiday vacation to get the company off the ground, to launch the Heroku AddOn. We then realized launching an AddOn meant building a cloud service…

Over those two weeks, or at least how I remember it, we had completed multi-organization support in Sentry, added in Stripe billing, and launched the product on top of Heroku. Stripe was a key ingredient that was extremely simple to integrate, especially with our silly naive business model at the time (a story for another post). While I’m sure I’m fudging the numbers a bit, I recall launching Sentry’s cloud service, a paid-only offering, to customers within a few weeks of starting development on it.

We launched it and that same day we had our first paying customer. Seven dollars baby!

Except it wasn’t that easy, and it took a lot of work to get to that point. It was certainly easy to add the billing functionality, and a few small features to the product, but that would not have been possible if not for the hundreds of hours already invested into the project, as well as the countless contributions from others. Let’s step back and talk a little bit about that, about how Sentry had product-market-fit from day one.

If you did the Math, you’ll note Sentry existed for about five years before we launched the cloud service. That was half a decade of natural needs-driven growth, either the needs of myself or the company I worked at, or the needs of others, users or contributors, who were running their own copy of Sentry at their own jobs. It’s often hard to understate how valuable this period of time was for Sentry, but I don’t think its as important how much time it was, but the way it was spent and the environment surrounding it. It was a passion for solving our own problems, compounded through peer validation. That validation often came through conversations at conferences, on GitHub, or on IRC. If you opened a ticket on the Sentry project you rarely waited long on triage and frequently new ideas or fixes were implemented the same day. I personally found a lot of satisfaction in that, but more importantly I believe it helped accelerate a product that was already solving real world needs, and build the trust thats so important in developer tools.

This is what I find somewhat difficult to translate to folks. One of the biggest challenges of a company is finding product-market fit, yet we had stumbled into it. So how do you replicate that? I don’t have an answer, but I genuinely believe that you are your own best customer. So when asked, I try to come up with the best advice I can, even if we didn’t directly face the same challenges. The advice I give folks is the best thing you can do is to find customers - yourself or others - that share the same desired outcome that you’re passionate about. In my case it was all about fixing the bugs I continuously created, and with less frustration. We found customers who understood that, and validated our ideas off of them. We did not however, listen to potential customers who wanted something that we disagreed with. I talk a little bit about this in Optimizing for Taste, but I thoroughly believe the best path you have to building a lasting product is by building something you’re passionate about, and have a strong thesis around.

I actually think this phase of building Sentry the most fulfilling, and the least demanding. Once we spun up the cloud service it meant being on-call (2x the pain when you’re also on call at your day job), having real customers to support, and dealing with all the backoffice involved in generating revenue. That, however, is a story for next time.

If you liked this article, I’d appreciate a share. Feel free to also reach out on X, I’m @zeeg. I’d especially be interested if there’s something you found helpful, or something you’d like to hear more about. I’ll probably write about our approach to pricing and packaging next, as its something I’ve become very passionate about over the years, and is particularly interesting due to how few companies there are like us in the IT space.

Update: Continue with A $7 Subscription.