Everyone likes to read great stories and posts about app development success stories. After all, wouldn’t we all like to be the next greatest thing? But to keep development projects in check, it’s also important to review the failures once in awhile. What hasn’t worked? Which projects crashed and burned? Knowing what failed helps you keep your development projects out of the danger zone.
1. Choosing the Wrong Vendor Partner
Make sure you’re not your partner’s first trip around the block.
Let’s start with what will go down in history as the worst development failure of the decade, and will likely be high in the running for the worst development disaster this century: Healthcare.gov. With two years and a seemingly endless supply of developers and funding, it managed to flop worse than ice cream shops in Siberia. The primary problem is that the contractor selected to oversee this project simply had no experience developing with NoSQL databases.
NoSQL is actually a great product, and has been the backbone of a number of highly successful, high profile development projects. But in the hands of newbies, it was disastrous. Never choose to partner with vendors that can’t give you a roadmap of their success stories.
2. Trying to Leverage New Technologies Not Yet Understood
Being the first to use an unproven technology can be the time bomb that detonates your mobile app.
Since Healthcare.gov was such an impressive disaster, let’s take a look at another element that helped catapult it into the land of laughingstocks. While NoSQL is a solid product, it was still relatively new at the time. Programmers and database administrators familiar with SQL will tell you that constructing and managing a database in NoSQL isn’t just different, it requires an entirely different thought process than traditional relational databases like SQL.
It’s popular to want to try out the very latest in development languages and tools, but in most cases it’s far better to stick with the tried and true standards than to be the first to achieve epic failure with the newest trendy thing. This isn’t to say that trying new things is bad; it simply means you should make sure you know what you’re dealing with, what it’s capable of, and how to use it before agreeing to be the guinea pig.
3. Accepting Micro-Downtime in Your App
Many developers don’t even go for the glorious epic failure; they simply achieve a death by a thousand cuts. This is what micro-downtime does for your app. Tiny database glitches and networking problems lead to a blip of downtime here and a smidgen of downtime there. The end result is that users think your app is crap.
Mobile users are notoriously impatient. Add to this that whatever app you’re developing — whether it’s a business app or game or news app or ecommerce platform — likely has hundreds or even thousands of competitor apps. If you can’t deliver a smooth, seamless service, your users will find someone’s app that will. Testing and debugging is crucial for eliminating micro-downtime. Don’t press developers to rush to market before this process is complete.
4. Failing to Invest for Growth
There are two things that kill companies, and the same principles can be applied to apps: not growing at all or growing too quickly. When an app grows fast, most businesses haven’t prepared properly by investing in enough storage and processing power at the back end to keep pace with new users. This is just as fatal as failing to achieve enough users to keep you afloat.
The key is to invest wisely. Don’t go overboard buying memory and CPU, but definitely buy more than you estimate you’ll need, and invest sooner rather than later when the growth begins. Make sure your users’ experiences can be maintained as you add more users and data to the systems.
5. Becoming a Pest to Your Users
Alerts and notifications are great! Users downloaded your app for information, so you definitely want to provide that. Alerts also help keep you and your brand on your users’ mind so that when they’re ready to shop or research, you’re their go-to guys. But it’s extremely easy to cross the threshold between helpful notifications and pestering the dickens out of your users.
What constitutes enough alerts versus over the top? More than one or two notifications per day starts to grind users’ nerves, and even that’s too much if the notifications come at the wrong times, such as before users wake up in the morning or after they retire for the night. The only exceptions are situations like sports apps, weather apps, and news apps. If users have signed up to get notifications when their team scores, when a dangerous weather event is imminent, or when important news unfolds, don’t deny them this. Also be cognizant of the time zones where your users are and avoid alerts at the times of day when ordinary people would be sleeping.
Unsure how to navigate away from potential failures and into the waters of sure success in app development? Visit Glance for a tried and true development process that actually works.