The move from mobile ready to mobile first has garnered much industry attention. Gartner projects that, by the end of 2017, demand for mobile app development will be five times more than development capacity due to the pressures of mobile first. Add to this the complexities for developing cross-platform mobile apps, as well as testing, maintaining, and marketing apps and costs skyrocket. Keeping these costs in check, or identifying areas to save on costs, can have a dramatic impact on a mobile first strategy and approach.
While the first stages of app delivery, and associated costs, are well understood and well covered, what about the forgotten next steps: the cost of instability? This article will explore the potential costs associated with even the rarest form of app instability.
Let's begin with examining a real-world example: a popular consumer app with more than 10 million monthly active users. It is inevitable that such a large deployment on a wide variety of mobile phones, operating systems, and configurations will encounter problems. For the quality assurance team, it is impossible to predict and test apps of this magnitude thoroughly. Every month a new phone model, a new OS update, a new carrier, and new user scenario emerges that causes instabilities, some so bad that they can sink growth and push the developers into overdrive.
Assume this app is 99.7% stable. This means the app will crash for only 0.3% of its users. While this is an impressive stability, it still means 30,000 users every month will feel the pain and frustration of service interruption. It’s been reported that more than 20% of users will abandon an app after only one use. This means 6,000 users monthly will be lost due to a rare crash or bug.
For further explanation and exploration of the costs associated with app instability.
let's apply this real-world scenario to the four pillars of a mobile app cost center: Marketing, Revenue, Support and Development.
Every company spends marketing dollars to acquire new users. ?Customer Acquisition Cost (CAC) are calculated as follows:
CAC = total_marketing_budget_this_month / new_users_this_month
The CAC can greatly vary depending on the industry and competition, ranging from $2 to double digit numbers in the gaming industry.
Using $3 as an example:
$3 * 6,000 * 12 = $216,000 / year
The cash bucket was leaking an alarming $216K every year due to a rare crash happening to only 0.3% of users – 20% of which were never coming back.
Every user is a future revenue stream. Recognizing every venture has a different business model and the expected revenue per user will vary greatly, for the sake of this example, the organisation makes $5/year on every user. Since the business is losing 6,000 new users, the potential revenue to be lost is $5 * 6,000 * 12 = $360,000 a year in revenue loss due to instability. It’s another big hole in the bucket.
The crash affected 30,000 users. Most users ignored it, some abandoned the app entirely, and some reported the issue. Say 1% of the affected users completed a support ticket – that's 300 new support tickets every month.
Support tickets also cost money. Again, it will vary significantly per organisation, but it usually involves a human and a few tools that help organise the stream of incoming tickets. Applying $50 per ticket: $50 * 300 * 12 = $180,000 / year
The cost of 300 users monthly (out of potentially 10 million users) reporting a rare problem costs the organisation nearly $200K annually. Another huge hole in the bucket.
A significant chuck of a developer’s time is spent on debugging. Some reports suggest as much as 75% or 1,500 hours a year is spent on fixing problems. There is simply no way to write perfect code. Developers and development teams split their time between developing and polishing new features and debugging existing versions of the product.
In this scenario, a team of 10 mobile developers have been assembled to maintain the app for 10 million users. That’s one developer per one million users – a healthy, albeit scary, ratio. Salaries will vary greatly depending on location. For this example, the team of 10 developers, spend 25% of their time debugging and troubleshooting at an annual salary of $100K: 10 * $100,000 * 25% = $250,000 / year
Totals and Takeaways
In this scenario, the organisation spent north of $1 million a year on a super rare bug that affects only 0.3% of users.
Lost CAC + Lost Revenue + Cost of Support + Dev Time =
$216,000 + $360,000 + $180,000 + $250,000 = $1,006,000
That's the price of instability. Reducing even a fraction of the $1 million burn will have a meaningful impact on the bottom line. To solve instability, and reduce its enormous price tag, organisations must strive to help developers understand and identify the root cause of a bug as quickly as possible. In doing so, organisations will experience faster turnaround time for fixes, reduce customer churn, lessen support tickets and increase revenues.