The #startup secret to launching bug-free apps, is DON’T
Launching your first MVP, Android app or website is a defining moment for #entrepreneurs and #startups. You’ve been working on it for several weeks or months, and the last thing you want to do is screw it up by releasing dodgy bug-ridden code. You want your app launch to be beautiful, and that users will be bowled over by your slick, cool, bug-free code.
Me too. Before I launched my first app (3 years ago), I spent weeks trying to perfect my app. I visited friends, family and user groups and watched them like hawks as they tested my apps. I spent long nights identifying every possible bug, and then spent days trying to fix them. By the time I launched, I was confident I had a slick good looking app. I was wrong.
The problem with bugs is that you – the Entrepreneur – can’t replicate or create all of them. There are thousands of different devices, hundreds of operating systems, a serious collection of browsers, and millions of very different and quite unique users. As a #startup you can spend hundreds of dollars using compatibility browsers and test-suites, but you’ll never replicate the unique user experience.
Despite your whiteboard brain-storming and months of testing, your users will still try to use your app or website in a way that you hadn’t managed, and some of them will break it, and they’ll tell you, and you’ll go “urgghhhh, I hadn’t thought of that”. And whilst you certainly knocked out several bugs, you’ve lost several weeks trying to achieve the impossible.
Let the market be your testers
3 years on, and I’ve learnt a better way of launching apps. It’s not rocket science, and most MVP #leanstartup guides will touch on this. The secret is NOT to launch the perfect app but to launch a reliable app with GREAT bug reporting, and let the users be your testers. The users test your app, and the bug-tool captures the issues, collates them and gives you the information to make the fixes.
Let users prioritise your bug fixing
The biggest thing we’ve learnt is that we as the developers aren’t the best people to prioritise bug fixes. I’m aware of a bug in our GPS Tracker app that I wanted to be fixed pre-release but didn’t. Surprisingly none of our users have encountered the bug. Why? Because they’re not using the same combination of device and Android O/S as me. Bugsnag (or any similar tool) will collate errors together, allowing you to quickly identify the errors that occur the most often or affect the most users, and it’ won’t be the bugs you expected.
To us, the ping of a new error on Bugsnag is dollars in the bank. Every new bug is an opportunity to remove that ‘pain-point’ for future users, but it’s also confirmation that we made the right choice in releasing our app early. Over 90% of the bugs that Bugsnag reports are bugs that as a bootstrap cash-restricted #startup we’d never of found on our own. By releasing early, we’ve saved several weeks testing, and we’ve not lost time fixing bugs that no-one else is likely to experience.
Please note: We’re not affiliated to Bugsnag, and not on their payroll. There are some fantastic error tools out there. We’re just describing our journey and our experience as a UK #startup. (a free t-shirt would be nice though).
Back to my earlier point on releasing reliable code. When you first write your app, you always need to do bug-testing. We understand that, so we asked ourselves at what point should code be released. In our opinion, the best way to describe the release-point is when the app is “reliable”. When it does what it’s supposed to in a reliable manner.
As a #startup #entrepreneur, we’re loving the community support both in the UK and abroad. We hope you’ll take the time to check out our GPS Tracker app at GridLocate and help us gather data, and we’ll be happy to help bug-test other #startup apps. We’re huge fans of Product Hunt and continually inspired by the great apps being released. Feel free to get in touch, and don’t forget to try out Bugsnag Error monitoring tool.