The real cost of mobile apps

Clients are often surprised by the cost of ownership of mobile applications.

That's not really surprising, since most companies don't specialise in product development, and the 'hidden' long-term costs of maintaining mobile apps could easily be overlooked.

Some may have dabbled with their own ad-hoc Web development, and have come to appreciate - and expect - a similar process with their mobile apps. The problem, of course, is that mobile apps are a throwback to the 'bad old days' of fat-client development, as opposed to the efficiency of the thin-client Web model.

To better understand the real cost of owning mobile apps, and how to manage them, the main sources of the costs need to be considered. These are the costs that follow the initial capital investment to develop the app, and the assumption that a multi-platform mobile application is being built, which is live on all the relevant application stores.

The impact of platform fragmentation has an almost immediate effect on the balance sheet. Depending on the business scenario, a company has probably built two or three versions of its app as 'native' applications for different platforms - iOS, Android, Windows, BlackBerry - each assigned to a group of people with two or three different skill sets.

Since labour is often the most expensive line item, this is where the first major cost comes in. For the life of the apps, a company will need developers with the appropriate skills - Java, Objective C, Android - and since it probably won't find one person with all these skills, two or more developers are being hired. Moreover, depending on the company's business continuity and redundancy policies, it possibly needs more than two of each. That's a minimum of three or four developers, continuously, for the life of the apps.

While it's true that cross-platform development platforms alleviate some of this burden, the reality is that the company still needs native plug-ins to enable certain features for almost all the cross-platform frameworks available today. On top of that, people are needed who specialise in each platform when it comes time to compile and submit the app to respective app stores.

But that's not all. A Web developer is also required, as the front-ends associated with these frameworks are generally based on HTML 5, CSS and JavaScript code. Either way, the company is back to a headcount of three or four developers, which is not always feasible unless it has some other reason to employ these people.

While mobile fragmentation becomes an issue at the development stage of an app, it's during testing that the real cost of fragmentation comes to the fore.

Consider, for example, that a company develops an app for three platforms, each with multiple OS versions, and intended for use on a large variety of devices, from tablets, to feature phones, smartphones and mobile kiosks. Let's assume further that the company has to implement new features regularly, because it subscribes to best-practice agile methodologies.

Automation is notoriously problematic for mobile app testing.

For these iterations, the company then has to complete regular regression tests before proceeding with app store submissions. Just consider the number of regression tests that need to be completed: application test scenarios, platforms, OS versions, form factors, device manufacturers.

It's obviously impractical to test everything, so a sensible sub-set of test cases has to be prepared, probably based on a fixed group of devices the company feels provides it with an adequate cross-section and covers its risk (remembering that it has to test on physical devices, and to get pre-paid SIM cards to test over each network, because not all issues will be identified testing in virtual environments or over WiFi).

In a typical development environment, the company would invest in test automation technology to reduce delays and costs. However, automation is notoriously problematic for mobile app testing. So unless the company owns all the devices that need to be tested, it may find testing costs can spiral out of control.

If the company's intention is to make its application available to its customers (as opposed to private, internal-facing apps), the customers will expect the company to support them when the application doesn't work as intended on their particular device.

That means someone has to be available to answer a phone, respond to e-mails, or monitor a chat service. That someone has to be trained and empowered to respond appropriately, as would be the case in any dedicated support centre environment.

The company could always limit the type and number of devices it supports, but this would still demand time and cost to manage appropriately.

The real cost of mobile apps is spread over an app's shelf life. Decisions made early in the development process can and will make a difference to an app's TCO, and there are numerous strategies that can be followed to minimise costs in the long run.

For example, the company could start with Web apps, and then expand. It's always easier to have the app well defined and targeted, and use existing resources to do so. Building an app based on a successful Web app is always easier - and less costly - than building it from scratch.

Policy management should also be addressed upfront. For example, does the company have a defined BYOD policy? If so, this will simplify its development choices. If possible, confine BYOD to a narrow set of devices and base configurations.

Define a strategy and roadmap, so the company knows who it's building for and its intended outcomes. Enlist focus groups for each app, so the company knows if it's hitting the mark. And, if possible, take the app beyond the confines of the business. Scale helps drive ROI.

Lastly, consider partnering with specialists that can guide the company through some or all of the process. App development is rapidly evolving, and it pays to have people with experience, skills and insight to develop the company's apps to their full potential.