Does building a mobile app make more sense than buying an off-the-shelf solution and customising it for your business?
There’s no clear-cut answer to the question, but it’s important to understand the differences between the two approaches as part of a broader mobility strategy. Unfortunately too many companies only ask the question after they’ve gone too far down the road with one or the other, spending time and money without getting a desirable outcome in return.
Exploring what your business needs from an app should always be the first step to deciding which way to go, and yet too few do the due diligence before calling the developers. Need CRM? Field service and facility management? BI dashboard? Chances are it has been built already, white-labeled and available for integration into your own hybrid environment without too much fuss.
Building a custom solution tends to be more expensive than retrofitting a ready-made app. The question then shifts to - what do you want the app to do for your business that is different to what’s already out there?
The point here is that the real purpose of a great mobile app is to provide the end user with the best possible experience of your company through their device. A banking app, for instance, becomes the primary interface with a bank, and in some cases becomes the primary way you do business with that organisation.
Looking at your app through your users’ eyes: what do you want them to see and experience, what do you need them to access, how do your want to transact with them? Is the app going to be little more than a static information portal, or will it give them access to dynamically changing content? Will they be able to generate reports and interrogate your business systems, or will they be limited to one-way communication with your support teams?
These are just some of the questions that derive from considering how your app fits into your broader business strategy as part of comprehensive mobility strategy.
Build versus buy is a decision that often somehow doesn’t factor much into the procurement process, and without sufficient research a convincing argument can typically be made for a bespoke application to be built. However, a solid R&D exercise in the investigative phase of a project will go a long way in addressing suitability and quality concerns. Look for apps from a vendor with a solid reputation, and license those accordingly where it makes sense to do so.
What’s not in question is whether or not you need to go down this path in the first place. It has largely become accepted that every company is a software company in one way or the other. If you’re not in software, if you don’t have a mobile app or a good web presence, you’re going to be ignored. Not every company necessarily needs its own app, but even asking ‘how mobile friendly is our website?’ could be a good starting point.
About DVT
DVT provides tailor-made software solutions and related professional services to clients throughout South Africa. DVT’s technology solutions include. Net and Java, enterprise mobility and data & analytics. Its range of professional services includes project management, business analysis, business process analysis, software quality assurance as well as Agile consulting and training. DVT’s product based solutions include Agile team management (Axosoft and Rally), performance testing (NeoLoad) and practice management (Thomson Elite). Visit us at www.dvt.co.za.
Editorial contacts:
Karen Heydenrych, Communikay, 083 302 9494, karen@communikay.co.za
Christopher Dawson, DVT, 011 759 5930, cdawson@jhb.dvt.co.za
Clients are often surprised by the cost of ownership of mobile applications.
That’s not really surprising, since most organisations 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, we need to consider the main sources of the costs. These are the costs that follow the initial capital investment to develop the app, and assume you’re building a multi-platform mobile application that is live on all the relevant application stores.
Development costs
The impact of platform fragmentation has an almost immediate effect on the balance sheet. Depending on your business scenario, you’ve probably built two or three versions of your 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, you will need developers with the appropriate skills – Java, Objective C, Android – and since you probably won’t find one person with all the skills, you’re hiring two or more developers. Moreover, depending on your organisation’s business continuity and redundancy policies, you possibly need 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 you still need native plugins to enable certain features for almost all the cross-platform frameworks available today. On top of that, you need people that specialise in each platform when it comes time to compile and submit the app to respective app stores.
But that’s not all. You also need a web developer as the front-ends associated with these frameworks are generally based on HTML 5, CSS and Javascript code. Either way you’re back to a headcount of three or four developers, which is not always feasible unless you have some other reason to employ these people.
Testing costs
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 you develop 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 you have to implement new features regularly, because you subscribe to best-practice agile methodologies.
For each iteration you then have 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 that you feel provides you with an adequate cross section and covers your risk (remembering that you have 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 you’d invest in test automation technology to reduce delays and costs. However, automation is notoriously problematic for mobile app testing. So unless you own all the devices you need to test, you may find testing costs can spiral out of control.
Support costs
If your intention is to make your application available to your customers (as opposed to private, internal-facing apps), they will expect you 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 emails, 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.
You could always limit the type and number of devices you support, but this would still demand time and cost to manage appropriately.
The bright side
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 you can follow to minimise costs in the long run.
For example, you could start with web apps, then expand. It’s always easier to have your app well defined and targeted, and using 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.
You should also address policy management upfront. For example, do you have a defined BYOD policy? If so, this will simplify your development choices. If possible, confine BYOD to a narrow set of devices and base configurations.
Define a strategy and roadmap, so you know whom you’re building for and your intended outcomes. Enlist focus groups for each app, so you know if you’re hitting the mark. And, if possible, take your app beyond the confines of your business. Scale helps drive ROI.
Lastly, consider partnering with specialists that can guide you through some or all of the process. App development is rapidly evolving, and it pays to have people around you with experience, skills and insight to develop your apps to their full potential.
This article was published on ITWeb on the 14th August 2013:
Platform fragmentation likely to continue as iOS, Android grow market share
Johan Pieters
Locally developed smartphone applications will continue to impress with unique innovations, despite the mobile development market becoming even more fragmented in 2014.
While smartphone platforms like iOS and Android will continue to win market share, they will also still be playing catch-up against cheaper feature phones that currently saturate the South African market.
There’s no escaping the fact that the majority of South Africans still use feature phones as their primary handsets, and this will continue to force a wedge between dedicated smartphone development and more basic services for feature phones.
Many software developers are addressing the mass market, developing apps and services from scratch using Java and other cross-platform frameworks, and this trend will persist well into next year.
That said I expect the level of innovation evident in locally developed smartphone apps to continue to impress – specifically in the area of accessibility and mobile security. The South African development community is nothing if not lively, and there’ll be plenty of evidence in this regard from a number of major outlets in the New Year.
One proviso to this trend is the dearth of mobile development skills in the country.
The skills shortage has become more pronounced this year and will continue to worsen next year. This drives up salaries and the cost of software development, and makes resourcing for major projects more difficult, resulting in delivery delays.
Although skills development – particularly at a junior level – is thriving, the impact won’t be felt immediately. Development companies are going to great lengths to attract new talent by offering a range of lifestyle choices – like work-from-home and specialised training – instead of increased salaries, which are already high due to the skills shortage.
We can expect this to play out in different ways next year, from an increase in in-house development, to a split between in-house development on popular platforms like Android while outsourcing development on other platforms.
A related trend that needs watching is the increased popularity of Xamarin for mobile development. The cross-platform development environment allows for a high-degree of code re-use using .Net wrapped up in a thin layer of native platform-specific code.
Code re-use is one way to save money on developing multi-platform apps, and .Net skills are far more prevalent than OS-specific development skills. With Xamarin we’re seeing up to 70 per cent code-reuse for each project, so the local market fragmentation combined with the growing lack of skills means solutions like Xamarin will be particularly important next year.
This will have a flow-on impact on the types of apps we’ll see developed by local companies, but I don’t expect this will result in a dip in quality – if anything I believe quality will be on the up across the board next year.
One anomaly will be the decline in Blackberry as the smartphone platform of choice for many South Africans.
The traditional Blackberry platform found a massive following in South Africa with its combination of smartphone-like features and feature phone-like pricing.
Next year will see a significant decline in the platform as the older Blackberry devices get replaced by the newer smartphone-focused Blackberry platform. The problem for Blackberry is that traditional users are not necessarily upgrading to the newer platform, preferring to move to iOS or Android or one of the other smaller smartphone platforms since the Blackberry price advantage is no longer in play.
Having an effective strategy is essential for digital transformation. Read more for our 8 tips on this, or contact us for more information today.
At first glance, South Africa’s highly fragmented mobile environment can seem a daunting prospect for any business wanting to develop its own mobile services or applications.
After all, applications (apps) have become one of the most direct and profitable means of reaching and interacting with customers. However, with so many platforms, operating systems (OSes) and devices to choose from, the options could initially seem overwhelming.
Fortunately, the extent of South Africa’s mobile fragmentation doesn’t mean there is any less opportunity for success. To make headway it is important to look beyond the fragmentation that exists and understand your target market.
The first thing the research tells us is just how complex the fragmentation is, particularly when compared to more developed economies. We can chart fragmentation along six lines: channel, platforms and OS versions, manufacturers, physical devices, app stores and browsers.
Mobile data communications are split among several different delivery channels, apps being just one.
The SMS channel is well used in South Africa but is expensive, and the complexity of SMS increases dramatically once you try to address foreign markets, like the U.S., where completely different SMS behaviours and regulations apply. SMS is best used to address the broader South African consumer market.
USSD (text prompts) is also popular in South Africa because it works on all GSM enabled devices and is relatively fast. USSD is not particularly pretty and is incompatible with some smartphone platforms, so is best used to address the lower end of the local consumer market.
Another notable split is platforms and OS versions. While overseas trends point at smartphone domination, with Android and iOS leading the market, in South Africa ‘advanced’ or ‘feature’ phones still rule the roost, with Nokia and Samsung-made devices dominating the sales charts.
Smartphones in South Africa are more often than not Blackberry, but even then overall smartphone penetration is only roughly 20 percent. The dominant Android and iOS platforms, with their respective OSes, occupy just a small fraction of that market. OSes are even more fragmented when their different released versions are considered, and the high number of different physical devices sold also has an impact, because the same OS can look and behave differently depending on the device it is installed on!
Another little-known fact is that there are as many as 71 different app stores worldwide. Even though a much smaller number of these are directly available to South Africans, an application distribution strategy needs to take this into consideration.
So clearly critical choices need to be made early in the development cycle when a business decides which apps to pursue.
Ready, aim, develop
Choosing what to develop, for which platform and OS, and for which device, becomes much easier when you know who you’re developing for. If you know your target market, you can very quickly assess which devices and platforms your business should be targeting.
The good news is that there’s plenty of reliable local demographic data available to help you correlate your mobile strategy with the types of mobile platforms your target market uses.
For example, the vast majority of ‘mom and pop’ small business users in South Africa still use feature phones rather than smartphones, and Nokia’s Symbian OS is the most widely adopted platform in this demographic. If your business is extending its services to this market, chances are you will want to focus your development strategy on feature phones first, with an eye on smartphone development as the market evolves.
On the other hand, if your business caters mainly to the higher-end white collar demographic – law firms, banks, creative industries, and so on – your investment would be better made in the niche smartphone segment dominated by Blackberry, iOS and Android devices.
Also consider that for business applications where the application will be used for a particular group of employees, intermediaries, brokers, field workers and so on, the possibility of issuing or specifying a particular platform becomes viable. This reduces development cost but also introduces other complexities, like device management and administration.
The cross-platform conundrum
When it comes to app development there still seems to be a stigma attached to cross-platform development tools, many of which are available license-free. While it’s true that these tools limit developers when it comes to coding more complex, processor-intensive and OS-specific apps like games, the vast majority of apps can be coded around a simple front-end with the majority of processing done on a backend server.
The point here is that cross-platform tools are the way to go if your aim is to save time and money by developing once and adapting your app to multiple platforms – feature phones included.
One important and oft-overlooked caveat is that regardless of how you develop your apps (or mobile websites), they should be tailored to the look, feel and usage paradigm of each platform they’ll be used on. This is particularly critical when developing iOS apps, given Apple’s (and the Apple App Store’s) strict human interface guidelines that prohibit any non-compliant app. In fact, when developing a cross-platform solution that includes an iOS version, my advice is to develop the iOS app first and adapt the other versions to follow.
But even for non-Apple development, it’s important to keep in mind how your target users will benefit from what you’re giving them. Nokia feature phone users expect their apps (or mobile sites) to look and respond the same way as any other native app, as much as Android or Blackberry users are accustomed to a particular way of interacting with their apps.
In closing, if you know who you’re developing for, the effect of the complex fragmentation inherent to South Africa’s mobile communications market becomes much reduced. There are some excellent (albeit proprietary) cross-platform tools available locally that allow you to cater for the whole gamut of mobile platforms, from ubiquitous feature phones to the small but growing smartphone market. And if you keep your apps light and simple on the front-end, you can save significant cost and development time by offloading most of the processing to your office or Cloud-bound servers.
Just remember to give your users the experience they’re after, deliver rich content that adds value to their business (and consequently to yours), and chances are your investment will hit the mark.
Apple’s ‘contactless’ payment system, Apple Pay, has signalled the arrival of payments to the long list of services we already entrust to our smart mobile devices.