Bugrocket Retrospective

Six years ago I, with some help, launched Bugrocket. It was my first major solo project, and it’s certainly been worth a lot from a learning and experience standpoint. But besides that…? It’s time for a retrospective!

Flying Bugrocket

Starting out

In 2009 I was working at Pingg (has since changed owners twice). We were plugging away making, in short, a better Evite (which was really bad at the time, they’ve since redesigned at least once of course). There were only a few of us working on the code. For whatever reason one of my big pain points was bug tracking. Maybe because we used Bugzilla.

Bugzilla 3

I resolved to find a replacement, but after poking at tons of them we just didn’t find anything that got us excited enough to go through the effort of switching. One night I decided to just see what I could come up with on my own. I would aim for the essentials/basics of bug tracking that a small dev team would need and nothing else.

Takeaways: There did exist several alternatives that would have worked fine for us such as Sifter, but somehow I convinced myself they wouldn’t do. I think a big factor was just me having the itch to work on something of my own.

Beta iteration

With a full time job the going was pretty slow. It probably took about 6 months of fiddling around, throwing stuff away and starting over, and major refactorings to get to a point where I thought I had something useful.

I used MongoDB which made sense to me because it was fun to use and didn’t require doing database migrations for every change to the schema. Since I was making lots of pretty far reaching changes every time I sat down to work, this seemed like a good thing.

MongoDB Logo

I was so on-board with MongoDB I even entered 10gen’s blog post contest and won a bunch of MongoDB stuff like coffee mugs and a backpack.

Once it was usable (and after proposing it to the boss and getting the go-ahead) I wrote some scripts to dump the Bugzilla database and then import it into Bugrocket, and all was well. We also ran a mostly open beta and took in maybe 30-50 accounts.

I felt, and still feel, like it was a good way to approach the product. We were exactly in the target market. While there were options that would have been fine, there still wasn’t anything as simple as Bugrocket was going to be (for example, GitHub issues didn’t exist when I started development, and it took a while to become very useful anyway).

By now I was starting to get excited and whipped up a blog with a static site generator I had been working on (long defunct) and starting writing down notes and ideas for posts. One of those ideas would later be published as the introductory post.

Here’s something fun – check out this embarrassing early homepage:

Early Bugrocket Homepage Yea, that’s the whole thing 😐… Look at that background colour! Wow.

Takeaways: In retrospect MongoDB was not a good technology choice for this project. I lost out on a lot of relational features that you’d think (correctly) would be useful for a hierarchical app like a bug tracker. I embedded ticket history inside the ticket documents, too, so I had a lot of performance problems trying to load larger lists of tickets, etc. It was also really immature at the time, both the database itself and the libraries to use it from Rails. This, plus my relative newbie-ness, unfortunately made the code more than a bit of a mess. I ended up spending quite a bit of time on some major refactors a couple years ago while adding some features. It still causes me pain every time I go in there to do something. Just use Postgres, people :)


Once we had been using it and running the beta for a while and various fixes and improvements had been made, I started thinking about a real launch. At the time it was pretty painful to start up a web business in Canada. Merchant accounts and I don’t even know what else. Stripe didn’t even exist, and then wasn’t available in Canada for quite some time. It was a non-starter for me.

The founders of Pingg got on board and helped me figure all that stuff out. Incorporation in Delaware, US bank account + Braintree account, accountants, lawyers, etc. They also put in some cash to pay for this stuff and some operating expense runway.

I was pretty active on a community called Forrst at the time, answering questions and so on. I talked about the beta there and got a lot of our beta testers and initial feedback that way. I made a launch post as well. Between that and a Hacker News post we got about 1000 hits during launch week (March 2011), and it stayed pretty steady for a while.

Early Bugrocket Pageviews

Of course there was a new homepage, here’s the above-the-fold:

Bugrocket Homepage v2 The clouds moved! 😮

The price was set at $20/month all inclusive (soft-cap of 25GB of file uploads which nobody ever came close to). At the time it was pretty unusual not to require a credit card at sign-up. I got some flak over it on Hacker News, but obviously history proved me right – most services don’t require a credit card upfront anymore.

Takeaways: I was pretty excited during the launch but I think it’s obvious that I didn’t really manage to get enough interest during beta/etc. These days the advice is all about starting marketing as soon as you start coding but that’s just not how I thought about it at all. I should have started blogging, tweeting, etc way earlier.

Growth (or not)

Traffic to the homepage later peaked around 3000 visits/month in November 2011. And that’s also pretty much the height of trial sign-ups as well.

Bugrocket Trails Over Time

We ran some standard ads, both text and images — looking at these ads from 2011 now… they do not age well!

Old Bugrocket Stuff

We tried some other marketing ideas such as an AppSumo discount and the Railscast Contest. These did pretty well, but it was slow going to find and do things like that.

After doing some math on our Google Ads results, the CPA was looking way too high – if I remember correctly it was something insane like $1000+/subscriber ($18 per visitor converted to trial via ads, 1-2% trial to subscription rate) which would take years of subscription to break even on. I stopped running them pretty quickly – instead trying to, typical developer that I am, focus on improving the product. I wrote a bunch of blog posts about new/improved features and also what we called ‘unfeatures’ (and sometimes both like Depends-on & Blocks) which were more or less stabs at the other bug trackers that have dozens of complicated features seemingly for the sake of it, or just to please managers. “Bugrocket is for developers!” I would say, but they didn’t know about Bugrocket and I couldn’t seem to reach them.

Another thing that got me sidetracked was doing an API. I figured surely developers would be more interested if there were an API! Data freedom! So I implemented a read-only API along with another static site for the docs.

Bugrocket Developer Docs Site Logo

A write API was planned but a grand total of 10 accounts (out of ~1500 total) ever made a request, only 1 of which is still subscribed today. Even sadder is that only 3 accounts ever made more than a handful of requests. So I abandoned the idea and left it read-only.

Takeaways: For my first ever commercial product launch I wasn’t bummed about the numbers at the time. We were signing up trials and converting some of the beta testers, etc. In retrospect though, it was really hard to generate any interest in a new bug tracker. I definitely under-estimated what an uphill battle it would be to actually get people to not only come across the site but also try the product. Nobody wants to talk about bug tracking or cares enough to consider switching from their current system even if they in-passing dislike JIRA or Pivotal or GitHub issues or whatever. Ultimately it feels like it’s just not exciting enough for there to be room for more options.

The startup valley of death

As you can see by the trial sign-ups graph above and the cumulative subscribers graph below — by mid-2012 everything was trending down (less than 1000 visits/month) and would never recover.

The problem was that we were throwing money at the traffic problem. Once we stopped doing that as much, things just flat-lined. Here’s the graph of the cumulative number of paid accounts:

Bugrocket Cumulative Subscribers

It looks like it’s growing pretty nicely there at the beginning. But remember that was launch interest + Google Ads which weren’t even close to sustainable. It’s just too expensive and too low-volume to buy keywords like ‘bug tracker’.

Also – churn! The subscribers graph makes it obvious, but it’s even worse when you look at just subs/cancels over time:

Bugrocket Churn Graph

Takeaways: I think one of the big problems is that burning through the investment made by the Pingg founders was stressful for me. I felt disinclined to propose spending money on things that I really had no reason to think would work. Should we sponsor a conference or a meetup? Should we find somewhere else to advertise? Should we pay someone to write more regular blog posts? Something else entirely? I totally stalled myself on the marketing side. So all of my effort was put into the application itself – not exactly a bad thing, but it wasn’t very helpful in terms of traction/revenue/etc. I should have realized that it was making enough MRR to pay for operating costs, so the funds in the bank should have been aggressively used to try and grow.

Some attempts to recover

Some contractors/freelancers were asking about using it for their client work. Client A should be not able to see Client B’s tickets, therefore I needed some access control features on a per-project basis in the app. Very few freelancers actually ended up using Bugrocket despite this feature, unfortunately.

The freelancers also helped push a decision to rejigger the pricing model. I had some smaller users complain that it felt like they were subsidizing bigger companies in a way because they were spending the same amount but using it way less. It got me thinking that maybe larger companies (by large I mean Bugrocket large, maybe 15 users) felt like it was too cheap, especially considering what alternatives cost. So off I went and did tiered pricing.

Bugrocket Tiered Pricing That weird beige background is finally gone!

It was one of those “let’s have a large plan we don’t really expect anyone to buy that makes the middle-tier plan look more appealing” situations.

After watching it for a while it was looking like that coincided with the traffic/trial drop-off, so it felt like a failure. Bugrocket is a very simple product and I think the tiers ended up being too big for its britches. Within a year I decided to go back to a single tier and dropped the price to $15/month instead of $20.

I was also starting to realize that it’s a big leap to use a new bug tracker. You spend time putting your stuff into it… but what if it sucks or is broken? I resolved to fix this problem by making a fairly elaborate tour system which involved the system making an account from a template-of-sorts and then using a side-project I had been working on – jQuery Tourbus – to walk the user through the various features and pages of the app. Try it out!

Bugrocket Example Tour Step

Takeaways: At the end of the day I just don’t think technology/features was the problem. The problem was traffic and traction. Not enough people were looking for bug trackers. Not enough looking for the kind of bug tracker Bugrocket is (it especially did not resonate with managers who, it turns out, often make the decision on which bug tracker to use). And not enough willing to take the leap and use something besides the big well known ones (nobody was ever fired for choosing JIRA, even if devs don’t like it).

Maintenance mode

By December 2014 Pingg had been sold and we were all working on other things. I had also been running CourseCraft with my wife for 2 years already and it was doing better than Bugrocket ever did. The other co-founders and I worked out a way to give Bugrocket back to me/wind down the US corp, etc. It would become part of the Canadian corp that already owned CourseCraft. I did a death-defying AWS account migration so some servers and such could be shared between the 2 apps saving a chunk of monthly cash.

Billing was moved to Stripe from Braintree since I was working for Stripe at the time and again I wanted to consolidate accounts and so on. I also went back to the original price of $20/month - talk about pricing churn!

Here’s the final pricing page with just the single option. Below this is a direct sign-up form.

Bugrocket Final Pricing

I also added a custom logo feature and Slack integration around this time. A lot of people use the logo feature and while it did bring in some traffic, hardly any use the Slack integration.

Bugrocket Slack Integration + Custom Logo As simple as that!

Of course there have also been bug fixes and minor improvements in response to feedback/support requests and such here and there, but largely the product is ‘done’ and I’m not spending much time working on it.

Takeaways: Losing a handle on the marketing and mostly seeing a 1-1 subscribe/cancel ratio put me in a weird spot. Should I shut it down? I do still like the product quite a lot! I’ve done a lot of freelancing (hey, you can hire me 😉) and used plenty of issue tracking systems as part of that, and I still don’t like most of them very much. GitHub issues is mostly fine, though, and a huge number of developers find it convenient to keep their code and issues in the same place. At this point I’m happy to keep it around as a pet-project, improving it just for personal (and the 22 current subscribers!) satisfaction.


Bugrocket costs are super low because of the shared servers I mentioned earlier. Plus with low traffic it’s not causing a lot of problems or needing a lot of scaling and so on. It brings in ~$500 USD/month (that’s over $650 CAD at the time of writing which is a decent chunk of the entire corporation’s monthly costs.

That means I don’t really have motivation to take any drastic steps. It has been suggested to me to shut it down just to get back the mind-share… but people still use it (there are customers who have been on Bugrocket for years!) and it doesn’t feel like a burden on my time/mind. Also a bit of nostalgia there for sure.

I’m pretty happy with how the visual style has evolved, how the homepage looks for the most part, etc. I feel like I can use it as a bit of a playground. If I feel like doing a redesign, I can just go for it and take that experience elsewhere. There’s something to be said for having a real project to poke at instead of just Todo-List demos all the time.

Occasionally I get the itch to do something with it, or encounter a weird bug to fix (recently I noticed a very long running bug with the you-were-assigned email that I’m shocked I and no one else noticed). Of course I also have to keep its dependencies up to date just from a security perspective.

Takeaways: So, I think Bugrocket is around to stay for the foreseeable future, and I don’t think I’ll change it in any fundamental way. It’s definitely been one of the most valuable learning experiences I’ve had in my career — it had a huge impact on my ability to launch CourseCraft. Even though it wasn’t a financial success (I mean, it is technically profitable!), it was still worth the time and effort spent. Going through all my old records to put together this post has, if anything, just made me itch to make another product… not sure if that’s a good thing or a bad thing :)

Bugrocket Current Homepage