Clutch spoke with Sarah Weller, London managing director at Mubaloo, as part of a series of interviews on mobile app cost and platform choice.
Please begin by introducing Mubaloo and your role at the company.
Mubaloo is a leading mobile consultancy and application development company. We focus on helping businesses with their mobile strategy across the whole organization, and we deliver bespoke applications across all the different platforms to suit their individual requirements. This breaks down into consumer applications, enterprise applications, and applications for partners as well. So, a whole range of different applications that are complex and often heavily integrated into backend systems.
My name is Sarah Weller. My role here, as London managing director, is focused on the sales and marketing side of the business, and I also have quite a big part in the location-based technology side. Mubaloo actually created a separate division of the company last year, called MiBeacons, to focus on location-based technologies. So, I'm involved with that side of the business and understanding how location-based technologies can impact our clients and different businesses in the market.
Mobile App Platforms
What are the objectives that a client needs to define before they select a platform for their mobile application?
I think the main thing is target audience. If they're looking to build a consumer application, then it's all about the analytics, if they have existing analytics and are already marketing themselves out to their target audience. Sometimes, we need to do research on their target audience in order to understand the penetration of different devices within that mix. So, we'll use analytics to say, "60 percent of your audience are on iOS, so let's start there, and let's think of Android as a second platform," or completely the opposite way around. So, it's very much about understanding who the company needs to get access to.
On the enterprise side, it's quite often a lot simpler. It's what devices the employees are using. If businesses have a BYOD, or Bring Your Own Device, strategy then, sometimes, we will look at HTML and either hybrid applications or wrapped Web applications if they need to get applications out to their entire workforce quickly and everyone's different devices. Other times, everyone on that team has been provided iPads or iPhones, so we know it will be an iOS application.
So, with enterprise, it tends to be platform specific or HTML, in my experience. Whereas with consumer, it will be iOS or Android first, and then moving forward on to the next platform. Sometimes, we have done both. It depends on the client. If it's a larger corporate client, for example a big retailer, they can't launch with only one platform because they need to make sure that they're addressing all of their audience. What we've seen is that, in the consumer world, Windows is typically the third platform to come up. So, Windows isn't first for consumers, but sometimes it is for enterprise if they're deploying Windows devices.
Is there an illustrative example from Mubaloo's experience of when it was best to go with Android first?
It's really the target audience. Some of our clients have come to us, and it's very clear that the audience they're targeting is 80 percent Android users. This might be geographical, or it might be based on the target audience within one country, and it just happens to be that there's more Android users who are interested in their product or services. The variances are so intrinsically linked to not general penetration across a certain country, or a certain audience type, but actually trying to get into specifics. We see quite a few organizations that come to us and say, "We want to build an application, so we want to build iOS first." But, actually, that's not necessarily the best way, depending on what they're trying to achieve.
What about examples of iOS first?
Hargreaves Lansdown is a financial services company with which we worked. They wanted to launch a tablet application. We looked at the statistics, and it was so clear that iPad was the biggest tablet being used by that audience, so we focused on iPad native application, and that's had an enormous uptake and it's doing really well. It needed to be native because of security, because of the user experience, and for a number of different reasons. It's a heavily integrated application because it's a financial trading application. It was really easy to see why that should be iOS because of the volume of people using iPads for that purpose. There are hardly any tablets other than that being used.
If they want the app to include in-app purchases, we have statistics that show that typically iOS users will spend more money in application than Android users. So, that can be quite a big driver for people to look at iOS first because they know they're going to be able to gain more revenue through that application. So, there's quite a lot of information to get into all around the analytics, understanding the target audience, understanding the specific user case in question, and the core functionality.
Are there any situations in which you found that the market you were looking at and the target audience were mainly Windows users?
To be honest, the only time I've seen it being mainly Windows users is in the enterprise, where they've done a large deployment of Windows devices to the employees.
It's definitely a platform that more people are considering, especially for the bigger brands. We're up to 10 percent market share for Windows now in the United Kingdom, so that's quite a big deal for some of the big retailers and companies that need to have their applications available to everybody, and for some of the social media channels as well. So, it's something that we are having an increase in demand for, and it's something that's increased throughout this year, but still, in the consumer space, it's the third platform, that's how we're seeing it.
Why would a client go hybrid versus native?
One of the things that comes up quite often is actually whether it needs to be native at all. As I mentioned with the enterprise side, depending on the functionality, sometimes you can have an HTML hybrid or wrapped application, and that's fine. We might recommend this if the app has simple functionality and if the client wants to have an impact quickly across their entire audience base.
For consumer applications, where we're looking at user experience being absolutely essential, that's another reason to go with native. Also, when the functionality is focused on the hardware as well, sometimes we have to build it natively because of what we're trying to access through the device. So, you really have to look at your audience and understand what you're trying to achieve in order to understand what the best approach is.
Are there any examples that come to mind illustrating use cases for hybrid versus native?
One is Eircom, a telecommunications company in Ireland. They wanted to use an application to decrease the amount of calls coming into their customer service helpline. The functionality was quite simple. It was accessing simple account information. We could see that a large volume of the calls coming in were related to simple account-based information that we could show through a mobile Web application. So, we were able to go out to the entire market at once as opposed to launching singular, native applications that weren't necessary for the functionality that was required.
I had the reverse situation recently with a client who was looking at HTML initially, from a cost perspective. I said fine, and we started speaking about the scope. But, when we looked at how much development time it was going to take to build the core functionality and scope that they wanted, it didn't make sense to try and build it with HTML because they wanted all this offline access. They wanted to access all these hardware features, which actually was going to be quicker to develop by going the native route.
Then, you also have the situation where, a person I spoke to very recently, who was talking about HTML applications, but then kept listing examples of apps that they wanted their app to be like that were native. To them, it was all about the user experience, and when I pointed out the differences, and showed them some HTML5 applications, which are also fantastic for this specific use case, they quickly realized the level of user experience they were after had to be native to suit their specific purpose.
Enterprise Apps - Key Drivers
What are the drivers or reasons behind building an enterprise app?
We see a number of different drivers for enterprise applications being built. Paper-based processes were something that we were looking at three or four years ago, but they're still there, especially when you speak to government organizations, National Health Service, places like that where they're still heavily reliant on paper-based processes. So, that's a big driver to move towards mobile.
Secondly, legacy hardware is another big driver. A number of our clients, RAC for example, where they have people out in the field using Windows PDAs [personal digital assistants] and various legacy hardware that is not reliable, and they also have to have paper, and they also have to have a laptop. It makes the sales process very difficult. There's a whole other range of processes that have been reliant on this legacy hardware. That's a really key driver for people in the enterprise moving towards mobile, because this hardware is no longer being supported. It's very expensive to replace, and it's really inefficient. When you speak to employees about their use of legacy hardware, most of the time, they're not even trying to use it.
Another driver is real time data access, which I think is relevant for enterprise, but also to consumers. So, the ability to access information in real time, and the efficiency that this can really have on a business, is a really key driver we're seeing. To give you an example, we worked with United Student Accommodation on an application for them. The core, initial driver was around a paper-based process, and this is facilities managers going out and fixing things in accommodation blocks that have been broken. So, a broken radiator, a broken tap, or whatever it might be. For them to be able to access job information in real time, to see where they need to go next and to have all the location details in there, and then onsite to record information in real time, they're now doing 30 percent more jobs on a weekly basis because of this app. So, the need for real-time data is just so important. We're also seeing this a lot in emergency services, again where they haven't been able to access this real-time data. We're seeing it with doctors, engineers, with a whole range of different people. Location-based technology is coming into this as well, but heavily on the enterprise side. So, actually inputting data in real time, to the actual servicing of the data, if we can do that immediately based on micro-location, or even use a Wi-Fi infrastructure and do it based on location, then we're making it even more efficient.
I think one of the other drivers for the enterprise is just the amount of people now working from home and working in the field. There are a lot of people now who work from home or are rarely in the office. That's quite a common trend that we're seeing. They still need to feel engaged and part of the organization. They still need to be able to access documentation, various content, CRM [customer relationship management], all of this kind of data, wherever they are. So, a lot of roles that were previously unsupported by information technology, who can work so much better having that support from IT. Businesses that haven't adapted to this are at a disadvantage. So, I think that this is another key driver, making sure that employees, wherever they are, can access this information.
Another one, a bit from left field, is actually recruitment. I've read a few interesting reports on this, and I was having this conversation with a company recently. Some of the graduates that were coming through, some of the questions they were asking were, "What mobile devices am I given, and what applications will I be using?" Actually, I think, in order to attract and retain top talent, businesses are seriously having to look at how people are able to work now. Businesses that aren't moving forward with that are finding that they're losing top talent. That's a genuine thing that I'm hearing, that graduates now have an expectation. This is how they work, this is the most efficient way to work, and so companies are trying to keep up with that trend as well.
One of the massive drivers throughout this whole thing is actually being led by the employees. Employees are using these applications because it makes their life so much easier. Companies have really realized a few years ago, but some are still only just catching on. If they don't provide these tools, then their employees will find them anyway, and they won't be approved. They will use whatever applications they can because they're just trying to do their jobs better, more efficiently, more effectively, and more productively.
I did a presentation once, and a company decided to open up their network to enable people to access the infrastructure from their mobile devices. They thought they were doing this big thing, and made a whole show about it. It enabled a few hundred people to go onto the network from a mobile device, and it was only when they tried to do this that they realized there were 9,000 employees already on it. They had found their own way onto the network without the approval of the organization because they needed to access content. They needed data that was on the server somewhere, and they were doing it on mobile without having it approved.
So, I think this has been driven by employees demanding it, as well as customers demanding it. If you speak to businesses and some of the services that they require from different suppliers, they have an expectation in a B2B [business-to-business] sense as well that they should have access to this information. So, the applications being built are B2B sales tools, just because of that expectation to be able to see their portfolio, and to see the latest product and the latest information through mobile devices. So, I think again, it's the level of expectation that already exists.
Consumer Apps - Key Drivers
What are the drivers for businesses building consumer applications?
I think, to be honest, it's a lot simpler with consumers. I think if businesses want to engage with customers, they need to have a mobile presence, they just need to. Consumers, everyday people, have expectations that a company will have a presence on a mobile device. In fact, it's pretty scary when a consumer goes onto a website to try and find something, and it's not mobile responsive, or they don't have an app, and they'll leave immediately and go to a competitor. So, I think you kind of have to have it now, there's no choice. I think the difference is how can you create applications that are really engaging, that really add a lot of value?
We do run a separate company under Mubaloo Group that focuses on responsive websites, and that's all about discovery, about people being able to access information and content wherever they are in a way that they can read it and make sense of it, regardless of the device. When we're looking at applications, this is about engagement and utility. It's about stick-ability as well. Being on someone's mobile device is precious. In order to stay there as a brand, you need to work. You need to make sure that your applications are engaging, that they add value to customers. If they don't, they won't use them.
I actually had a really interesting meeting with a very large retailer in the United Kingdom about exactly this today. We were talking about their existing applications, and something that the majority of retailers in the U.K. are very aware of is that, as far as customers go, omni-channel is norm now. Everyone keeps talking about omni-channel like it's some new trend. Customers already expect it. Customers expect consistent experiences from brands, especially large brands. If they're not getting them, they're already disappointed.
Mobile App Cost
In terms of pricing for a mobile application, how does Mubaloo estimate the price and then charge the client?
It's really simple, actually, the way that we come to it. We're very transparent with our costing. It really is based on the time it takes. Sometimes, we will do workshops with clients, and we charge for our workshops, but that's very much the consultancy side. That's kind of big, strategic, building road maps, or looking at applications from scratch. So, that's quite a different thing. When we go onto specific applications, we will scope that application and create a proposal. Then, we will discuss that proposal with the client, and make sure that it's completely correct.
When we have the scope, then what we do is, we sit down with the designers, the project managers, the developers, the QA [quality assurance] department, all the different teams, and understand how many days this core piece of functionality, this element of design, this QA, how many days all of this is going to take. Every single person in the company on the delivery side has a day rate. So, depending on if they're a senior, middleweight, junior developer, designer, QA, or project manager, they have a different day rate. We appoint everyone accordingly to form the team.
It's very much a case of this piece of functionality is going to take three days to build. This piece of functionality is going to take 10 days to build. This design is going to take us 25 days. Then we simply go, it's going to 20 days. Here's the day rate; that's how much it costs. Add it all up, and that's the cost. We share all of that with our clients so that they can look at it and say, "OK, actually wow, that piece of functionality is going to take 30 days? Can we move that out and put it in Phase 2? Or, actually, now that I've seen this, can I add in some more functionality up front, and see how much time that's going to take?"
So, it really is a simple calculation. We have support and maintenance contracts, which are typically 20 percent annually of the total build cost. So, for OS [operating system] updates, for device updates, looking at the analytics, working out continuous improvements, all those sorts of things that you would expect for a support and maintenance contract. That's kind of a separate model. MiBeacons, the location technology, is a completely separate costing model, but an actual application is simple.
Don't get me wrong, it can be quite hard to cost sometimes, but that's why we have so many conversations upfront, and we try to get all of the relevant people in the room. We had too many instances when we first started five and a half years ago where people would say that the back-end infrastructure was in place and where it needs to be, and they could send us the APIs [application programming interfaces], and then we'd get to that point and they weren't ready. The last thing we want to do is give a quote and a timeline to our clients, and then something happened from their end and it kind of messes all the timescales and budgets up. That's not fair for our clients, so we really try and quote as accurately as possible.
We have lots of sign-off processes. Wireframes get signed off on. We have function specification documentation, technical specification documentation, information architectures, and screenshot designs. All of these things are sign-off processes. So, if there are big changes later down the line, then we have change requests. Again, if it kind of veers away from the original scope, which is very detailed before we start, then we will again look at the new elements being added in. How many days it's going to take to build, design, QA, whatever it might be, project manage, and then say, "OK, this is how much extra it's going to cost you." So, we're very black and white with our costing, with all of our clients.
Is iOS or Android more expensive to build, or are they about equal?
There's really not very much difference. I mean, with Android there's more testing. I personally really don't see much difference. I think one of the things people are always shocked by is that they think if you've built an iOS app first, and then you go to build an Android app, that there would be some level of cost savings because you're building the same app on a different platform, but actually, there is hardly any. All the code is in a completely different language. All the designs are completely different. There might be the planning time, but we don't charge for that anyway. So, that's one thing that does shock people. They think, "We've done it once, the second platform will be half the price." It's really not. It's pretty much the same cost again.
The only time you would find savings is if we had to spend a lot of time creating a back-end service to work with the mobile application. Once that's out of the way, then that's when the second platform becomes much cheaper. If all you're doing is making APIs, making different Web services, and pointing it towards an app where the main thing is the design the platform coding, then obviously that makes the second platform a lot cheaper. Once you've got the API's in place, you just reuse them. But, the actual time spent on the design, and the build of the front-end application, you really don't get a huge amount of savings.
Does Mubaloo have a minimum budget that you require, or a budget with which you typically work?
The average cost of an app that we build is between, I'd say, £50,000 and £70,000 [$78,000 to $109,000] per platform. We've built applications for £250,000 [$400,000] plus. We've built applications for £30,000 [approximately $50,000]. We have a very professional process that we've worked really hard on during the last few years, and it doesn't suit people who are looking to try and get something out there for £5,000 [$7,800]. That's not how we work, and everybody kind of knows that. We're quite open with people about that. For really simple applications, it's still going to necessary to go through our process because we need to make sure that it's been tested in the right way, and all these sorts of things. Then we will still look at applications for £35,000 or £40,000 [$55,000 or $60,000-plus]. They don't typically tend to be less than that.
All the costings that we're talking about there are end to end, from strategy all the way through to QA and deployment. But, some of our clients have in-house development teams, or some of them work with creative agencies. Sometimes, they'll come to us and say, "Mubaloo, please can you do the iOS development? We're going to give you all the designs. We're going to support and maintain it. We're going to do the integration work. We've got our own technical architect. Please, can you just do this element and this element?" Obviously, from a cost perspective, that's very different, and we'll look at it on a case-by-case basis, and then we just work out the number of days. So, it doesn't have to be end to end with every client.
We also do a lot of prototyping, which again is a very different price point. We can do prototypes for anything from £7,000 to £20,000 [$11,000 to $30,000-plus], depending on how complex it is. We will happily work with a client on building them a prototype to fulfill their requirements. Sometimes, they need that to get buy-in from their management team. Sometimes, they need it to understand that the market is ready, or to get some customer feedback. We always encourage prototyping anyway so, again, that's a different entry point.
Also, some people actually just want to speak to us about consultancy. This is typically for large organizations that have entire in-house mobile teams with designers, developers, all these things. They don't necessarily have mobile consultants at the level that we do, so they'll come to us and say, "Mubaloo, can you come in and run a series of workshops to help us build our roadmap?" So, again, there are a few different pricing points. We have to be very flexible because everyone, as you know, everyone is at such different places with mobile. Everyone has different teams. Everyone is thinking about it differently. Everyone has different back-end infrastructure. There are so many differences that we have to be flexible and work with our clients in the best way it suits them.
In terms of your business model, everyone is in the U.K., correct?
Yes. That's really important to us. We don't outsource any of the work that we do. The offices we have in the U.K. are in London and Bristol. All of our developers, designers, QA, technical architects are all based in Bristol, and we will never outsource.
How is your business model different or beneficial from a cost or value perspective, compared to other companies' models?
I think we're definitely more expensive than companies that outsource their development work. We know from our experience during the last five and a half years, we've had numerous companies say we're too expensive and they're going to go with a company who outsources work because it's that much cheaper, and then they end up coming back to us. That might sound brutal, but that is the truth. Our developers will be onsite with clients if they need to be. They are in constant communication. All of the documentation is completely clear and always approved.
Don't get me wrong: to each to their own. Sometimes, the outsourcing model will really suit people but, for our customers, it doesn't tend to because they like having those frequent sign off processes. They want our developers to work with their developers. They have system integration teams that they need us to liaise with on a frequent basis. Even things like time differences can cause issues. Also, if you look at some of our clients that we work with, they have an expectation of the kind of documentation that's going to be written that makes it easier for them to continue managing the applications if they want to. So, outsourcing is just not for us, and it's not for our clients.
I think one of the other things that might be different about us is that we never own any of the IP [intellectual property] on anything we build. Everything is owned, always, by our clients. Sometimes, developers will do a revenue share with customers they want to work with, or they will own the IP. That's just not our model. Again, it comes down to what our clients want, and they want a professional consultancy and app development company who's going to create bespoke applications that they need, that suit their very specific requirements, that integrate with their very specific back-end systems. I know that's something that really important to our clients.