After spending eight years consulting on web sites and applications with a focus on front-end development, user experience, and information architecture, I had been relentlessly disappointed with the lack of a simple bug and issue tracker. While the existing solutions and their complexity worked well for large dedicated teams, they were overly complex for our predominantly non-technical clients.

For years, I’d watched as clients would log in to issue tracking tools once, get overwhelmed, and fall back to simply emailing issues. While we could usually keep track of them internally, issues would inevitably slip through the cracks. Or, the chain of communication between developers and clients would be lost in individual inboxes, and the updates wouldn’t make it back into our issue tracking system.

Day-dreaming & Designing

Just for fun, I started dabbling and day-dreaming about a simplified bug and issue tracking workflow. One thing led to another, and I started creating rough designs around the ideas and sharing them in a series of blog posts.

At the time, the whole process was little more than a fun exercise to share some ideas I couldn’t stop thinking about. I thought maybe I’d create an open-source application, but that was the extent of it. Over time, however, people started asking if I was going to build it. Initially, I pushed back, but eventually, there was enough interest that it felt worth giving it a shot. I threw up a placeholder page to collect emails and started building my first commercial Rails application.

Going All-in

[A screenshot of a simple two-column issue detail where the conversation and change history filled the larger left column and the status, priority, assignee and other key metadata each received a custom visual treatment to provide a sort of at-a-glance visual signature for the overall state of the issue.] A screenshot of a simple two-column issue detail where the conversation and change history filled the larger left column and the status, priority, assignee and other key metadata each received a custom visual treatment to provide a sort of at-a-glance visual signature for the overall state of the issue.
Figure 2

Throughout my years working on Sifter, ensuring a human-friendly view of the issue details as well as the process for updating issue dominated my thoughts.

↩︎

When I decided to go all-in and build Sifter, modern tooling for SaaS applications didn’t exist. Authorize.net was the de facto payment processor, the popular email service providers were only just getting started, and virtual hosting was in its infancy. I had been dabbling with Rails for about a year, but I didn’t have any deep experience running it in production. The first commit was to a Subversion repository.

While I had never been completely responsible for an application, I had been involved enough to know how to approach each of the processes and services the application would eventually need. Juggling part-time consulting work with Sifter, I was able to have a working application to beta test in Fall of 2008.

Going Live

In late 2008, I officially launched Sifter and begin an eight-year journey of trial-by-fire learning more about hosted SaaS applications than I ever imagined. Marketing, customer support, search indexing, background jobs, cron, database management, Ruby and Rails, billing, payment processing, security, email, and so much more.

Going Full-time

In 2010, …

Working with a Curve ball

In 2013, a minor ankle surgery…

An Evolution

In 2015, after Sifter had grown a bit, it was clear that the design and information architecture could be more cohesive and integrated. I started dabbling with some new ideas for a more unified and deliberate interface. The primary focus revolved around the information architecture and navigating both projects and account settings. I had years of accumulated feedback from customer support, and I set out to catalogue and address all of the short-comings.

The end result wasn’t a complete redesign, so much as an intentional set of adjustments to unify the design language and underlying interface elements. You can read more about the full details from the blog posts about the navigation redesign and the notifications redesign on the Sifter blog.

Time to Move On

In early 2016, the interface evolution had wrapped up and stabilized, but my ankle fusion recovery wasn’t going great. Amputation was increasingly feeling like the right long-term move. It was still off in the future, but I decided that I didn’t want to navigate that decision and the recovery while also continuing to run Sifter as a sole founder. I made the decision to sell Sifter and joined Wildbit to help grow Postmark.

A few months after joining Wildbit, we were set to close with a buyer, but the night before closing, they made a last-second demand that didn’t feel right. I decided to walk away from the deal after losing trust in the buyer.

In March of 2016, we sold Sifter.