Our greatest achievement: The software we never plan to ship

We’ve been busy… crazy busy… in the past couple years, developing apps for a variety of clients and third-party vendors. Chances are you’ve seen our work, even if you don’t know it’s ours (we’re like secret Santas in that). The projects have been varied, but they’ve all had one thing in common: A need to keep track of issues, requests and, yes, even bug reports as we’ve progressed from initial discussion to launch (and then some).

Over the years, we’ve used more bug-tracking and project-management software than we’d care to count: Jira, MantisBT, Assembla, FogBugz, Fossil, Redmine, Bugzilla, Pivotal and the list goes on. They all have their merits and their pain points, but no matter which system we’ve used (often at the request of clients; sometimes thanks to our own misguided efforts to find the right system), we always ended up using just a sliver of the functionality presented via the UI -- often navigating past multiple form fields just to enter the 5 or 6 items we actually cared about: Product, version, bug description and history, for instance.

That all ended (not abruptly, but it did end) about a year and a half ago, when we started using a system we developed in-house just for us and our clients. We call it, appropriately enough, “the in-house bug thing.”

It’s plugin-based (so we only use -- and see -- the information we care about), REST-driven (with a simple Bootstrap theme for its Web front-end and a handy iOS and Android front-end for those that prefer that too), and we’ve noticed our testers are not only logging bugs more thoroughly, but our developers are solving and marking them off quicker too. It actually IS enjoyable to use, and it DOES adapt to our company AND our developers’ ways of “getting things done.” I personally never “see” it, as I use my faithful OmniFocus app as its interface: As new issues arrive, they appear in my inbox, and as I complete working on them, they’re appropriately marked within the bigger system. A co-worker manages to make it work via black magic and dropbox, another handles it all via his email client, and our customers are just happy to have a usable Web interface that they can use to “see into” the entire process.

We’ve considered offering the system as a service to others (or open sourcing it for others’ use), but as we’re not in the business of supporting bug-tracking software (nor do we want to be), we figure for now we’ll let it just be one of the little things that makes our company different in an otherwise crowded field: The bug thing makes it easier for clients to work with us, developers to work for us and our software to just work.

So think about that when building your own in-house tools: Sometimes, you need to build just what you need -- not what you think the market wants.