For the uninitiated, I, nor any other developer, actually eats dog food (not that I know of anyway). The term “Dogfooding” simply refers to the process of using your own tool to build your own tool. Wikipedia describes it as “a slang term used to reference a scenario in which a company uses its own product to test and promote the product”.

So in the case of Task Rocket, I use Task Rocket to manage the development of Task Rocket. In fact I’ve been doing that since the very first release two and a half years ago.

This approach comes with some obvious benefits, with some that come to mind being…

• You’re likely to spot issues sooner while using your product day to day
• Your experience will be closer to what your customers experience
• Constant usage of the product may reveal UX or workflow issues you never considered
• Feedback from the team and stake holders can offer a different perspective than your customers
• Constant usage may reveal critical/security issues that customers might not have a chance to discover
• If it’s known that you use your own product, the market will have more confidence in it

…and I’m certain there are more I can’t think of right now.

It’s important to understand that while dogfooding will make you and the team more intimate with your product, and by default result in a better product, it’s by no means a substitute for rigorous feature-by-feature testing.

You still have to test thoroughly, get feedback from beta testers (if you have any at your disposal), and test again ad-nauseum. Dogfooding is simply another tool in your arsenal to help deliver a better product.

No software is perfect, and no amount of testing can 100% guarantee you won’t release a bug-free product (but you’ll get close). Many apps – including Task Rocket – are released with unintentional bugs that aren’t discovered until later down the track when a customer uses the product in ways you never expected or intended, despite your best efforts to avoid that.