We’re all shipping bugs. (Yup. Even us.) It’s impossible to ship perfect code, but with a dab of process, and the right tools for your team and situation, you can catch the majority of problems. While bug and issue tracking isn’t the only way do that, it plays a big role, and it’s the easiest way to get started improving your quality.

Is Sifter right for your team?

There’s no shortage of choices when it comes to issue tracking and project management software, and Sifter’s not any better or worse than the other options. It’s just a little bit different. The best way to find out if Sifter’s a good fit for you is to run through some questions about you and your team…

Do any of your clients or non-technical team members “log” issues by emailing them to you?

Over the years, we've observed that non-technical people often prefer using email to report issues, but it's too easy for issues to be lost in everyone's overflowing inbox. Sifter embraces email to make your life easier by making it easy for anyone on your team to report issues directly to Sifter via personalized email address. They can even update issues by replying to notifications.

Do your project teams, including clients and stakeholders, usually have about 2-15 people on them?

Sifter forgoes a lot of the ceremony of bug tracking in favor of keeping things simple so you can spend less time configuring-and-classifying and more time resolving. Because of that simplicity, Sifter works best for smaller teams. Quite a few larger teams use it as well, but most large teams are too deeply entrenched in process and bureaucracy to keep things as simple as Sifter requires.

Are you overwhelmed with irrelevant notifications from countless tools?

Issue tracking requires precision, and too many notifications can drown the signal with noise. Sifter is designed to send fewer notifications by focusing on only notifying the key people for each issue. Others can choose to follow along, but Sifter strives to be judicious with notifications.

Is your team often unsure about priorities of various bugs and features?

Sifter is just flexible enough to support new development and bug tracking in the same system and offers a single priority field. So there's never any confusion about what's next for development, and new features and bugs are forced to compete on a level playing field instead of having bugs in a separate system destined for neglect.

Do bugs and issues slip through the cracks with your current approach?

Sifter is designed to avoid having any deep dark corners where issues can hide. We don't allow issues to be pending or on hold where they can be brushed under the rug, and even unassigned issues get top billing throughout.

Would you prefer to not pay more just to add clients or stakeholders that may only use your issue tracker for a short time?

Issue tracking and testing require expert involvement, and the best way to achieve that is to ensure that everyone has access. We feel you shouldn't have to pay more for better testing. We don't believe in user limits, so you never have to waste time managing head counts. Spend that time resolving issues instead.

Are you looking for a tool that doesn't require extensive training before someone can use it effectively?

The biggest benefit of simplicity is that training isn't necessary. Your senior folks spend less time training, and your junior folks can contribute sooner. You save time and money shipping higher quality software.

Do you need an audit trail to help reference past decisions?

Every issue-based action in Sifter is recorded so you easily review past decisions and the thought process that led to the decision. That way, you never have to have the same conversations over and over again.

Do you prefer that your team not spend time managing security updates, uptime, and performance for your tools?

Self-hosting works for huge companies that want to keep everything on site because they have the people to manage those tools, but small teams have better things to do than manage servers and security updates. Sifter is hosted so that reliability and availability is our job. Curious about the details of our security and backup strategies?

Do you believe it should be as easy to cancel a service as it is to signup for it?

We've made Sifter incredibly easy to cancel. In fact, it's even easier to cancel than it is to create your account. You never need to email us to ask for a data export or cancel your account. We hate to see customers leave, but if you're ever ready to move on, we believe it should be easy for you.

Sifter won’t be right for everyone. Instead of focusing on enterprise features, our focus is on keeping things simple so that you don’t have to have years of quality assurance and testing experience to improve the quality of the software you create. If you value simplicity, Sifter may be a great fit.

Thanks to its simplicity, Sifter actually makes bug and issue tracking accessible to groups who may have never considered it before: Web developers, blogging teams, community managers, graphic designers, and the like.

Our Manifesto

We’ve spent years working with teams and projects of all sizes. Over those years, we’ve seen perfectly executed testing strategies, and, well, less than perfect testing strategies. We’ve also found that there’s a few philosophical approaches that make testing more effective for small nimble teams like yours, and that’s influenced how we design and build Sifter.

• Participation is everything. User limits impede issue tracking. Developers might use your issue tracker regularly, but clients or stakeholders might only use it during brief periods. Sure, we could make more money restricting the number of users on your account, but with fewer people, you’d find fewer bugs.
• Non-technical people should test too. Creating software requires more than developers, and we believe issue tracking works best when it’s simple enough for non-technical people to contribute as well. If key team members can’t or won’t use your issue tracker, all of the functionality in the world doesn’t matter.
• Overclassification is counter-productive. Some huge organizations like NASA, Microsoft, or Apple genuinely need dozens of data points and attributes to resolve an issue, but for smaller projects, it’s just classification for classification’s sake. It slows down reporting and adds unnecessary noise and overhead to getting things done.
• Unreported issues are the worst. Better to have an issue reported and need more information than have no issue reported at all because the tool was too complicated or intimidating. We believe bugs and issues don’t need life stories up front. It should be quick and easy to report issues, and just as quick and easy for developers to request more info on the rare occasions that it’s needed.
• There’s no such thing as a “pending” issue. Marking issues as “pending” or “on hold” is the digital equivalent of sweeping things under the rug. It tidies things up a bit, but the issues are still there. The only difference is that when they’re on hold, they’re easier to forget about.
• One assignee at a time. When issues have multiple assignees, it’s way too easy for everyone to believe someone else is doing the work, but with only one assignee, there’s nobody else to point fingers at. Of course you can always reassign, and others can chime in, but with Sifter, there’s only one responsible individual at a time.
• It’s best to have one true priority. Priority. Urgency. Impact. Severity. Due date. Too many priority-like fields leads to ambiguity. Ambiguity leads to confusion. And confusion leads to… Nevermind. Huge lumbering organizations may need that kind of detail, but nimble teams don’t. One priority (plus due dates for groups of issues) will work. Then priority has the meaning that matters: “What’s next?”
• Tagging is messy. Tagging brings all of the drawbacks of overclassification without the organizational benefits. It’s inaccurate (typos), unreliable (forgot a tag), and makes it more difficult to organize issues (synonyms and such). Tagging is the number one culprit of issues slipping through the cracks because they were mis-tagged. And if issues slip through the cracks, that kind of defeats the purpose.
• Notifications should be judicious. We’ve all used tools that send notifications to everyone for even the smallest things, and the consequence is that people begin to ignore notifications. We believe notifications should be selective and focus on notifying the right people for an issue, not just blanket notify everyone.
• Email is an interface. Sifter offers deep email integration so that anyone on your team can create or update issues via email making it much easier to log issues on the go. What’s better, your non-technical team members that may be less comfortable with issue tracking can just use email without having to learn a new system.
• Infrastructure is distracting. Large companies may have the resources to self-host their tools, but small teams have better ways to spend their time. We obsess over our infrastructure so you never have to worry about whether it’s secure, available, or fast. We’ll take care of that.

Issue tracking is hard work. Shipping software with fewer bugs is 50% discipline and 50% having a tool to support and encourage that discipline. Using an issue tracker like Sifter will only go so far. Ultimately, you'll want to put the processes in place around Sifter for testing and release processes. Just like the tool, these processes work best if they're simple and repeatable.

I don’t mind logging support calls now I have Sifter. Still hate resolving them though. Seems to be no feature for automatic resolution… Simon Young

➥ View more testimonials…