Clutch spoke with the Myriad Mobile team as part of a series of interviews on mobile app cost and platform choice. Adrian Dawson-Becker (mobile strategist), Sam Stutsman (Android software engineer), and Brandon Kobilansky (iOS team lead) shared their thoughts with us.
Please begin by introducing yourselves.
Adrian: My name is Adrian Dawson-Becker. I'm a mobile strategist with Myriad. My primary role is to provide pre-production consultation and planning services, and do all the initial documentation needed to facilitate the development process.
Sam: My name is Sam Stutsman. I am an Android software engineer here at Myriad.
Brandon: My name is Brandon Kobilansky. I'm an iOS team lead here at Myriad. I do software engineering and some management.
Can you tell us a little bit about Myriad Mobile?
Adrian: Myriad Mobile has been around for four years. Our key service is developing native applications for our clients. We develop for iOS and Android, and to a lesser extent, Windows phone and Windows 8. We also do some hybrid web apps, but the core focus of our business is developing native applications. We're not currently pigeonholed into one vertical. We have done plenty of machine-to-mobile, retail solutions, and business-to-business-type applications. We try to embrace new technology as frequently as possible, so things like iBeacon, location aware applications, and wearables. Anything that we see coming down the pipe, we try to jump on as quickly as possible and offer those solutions to our clients. We aren't limited to our own region; we have field representatives in Los Angeles, Atlanta, Chicago, Kansas City, Denver, Fargo, and Minneapolis, so we service the entire country through those contacts. All of our development work is done in Fargo, N.D.
Mobile App Platforms
What are the items that a client needs to define before they decide on a mobile platform?
Adrian: There are a couple things that we talk to our clients about. First, we look to see if there is a specific phone in use in their demographic. If we're talking to a major enterprise corporation, and they distribute devices to their users, it makes our job pretty easy. Otherwise, we have to search for a little bit more information to decide whether we should focus on one specific platform and which one to focus on first, or whether we should target all of the platforms, depending on the size of the market they want to reach and the budget that they have. Depending on who they want to reach and how, or if there's specific hardware they need to use, there are many different questions that we ask.
Many times our clients come to us with a specific platform in mind, primarily iOS and Android. Most of our customers want to do both of those platforms. We have seen a lot of interest in Windows phones, but the market share has been pretty low, which makes it a little harder for our clients to set aside budget just to reach the Windows clients. That's not because they don't want to, or don't see a need, it's just because the return on their investment isn't large.
Hybrid apps and Web apps are primarily geared towards those people who want to reach as many users as possible across all platforms, but don't quite have the budget to develop on all three platforms natively. If they are good candidates for hybrid apps but they don't use any native libraries or capabilities of the hardware itself, this allows us a little more flexibility to do a Web app, if they don't want to deploy into a store or something like that.
Are there any particularly illustrative use cases from your experience for the hybrid approach?
Adrian: One of our current clients came to us and said their users are on iPad, so initially they wanted to do native iPad development for a sales and marketing tool repository. They want to store sales and marketing documents, and then also detail their sales process so that their sales people know when they should present certain documents along the workflow. We found that what they really wanted to do is manage all of that content externally using tools that they already know. They also weren't sure if all of their sales people were going to use iPads. About 75 percent of their sales force uses iPads. The other 25 percent have iPads and just don't use them. So, we were looking for a way to get a tool into the hands of users that they would actually use.
By approaching it from the hybrid viewpoint, we can still do a touch first interface that is accessible from not only phones, but tablets as well, and also desktops. So, we expanded their user segment exponentially by allowing them to have a tool that could function on whatever platform their end user is most comfortable using. That was the determining factor. They wanted to reach as many users as possible. They still wanted it to be touch first, but they realized that developing on iPad might not be the best choice.
Sam: One example I have is, we had a particular client that had a large amount of work already done from a Web perspective. They went with a hybrid approach in order to transition. They knew they wanted to have a native app moving forward, but they didn't want to waste all the work they had already done. So, we went for the hybrid approach to kind of transition them. We broke down what functionality we could break apart in pieces, and which we could transition to a completely native approach. We could transition them over time as opposed to making them spend however much money to completely do everything native right away.
Can you describe why a client would go with Android versus iOS? Are there any kind of technical differences between the platforms that really require one compared to the other?
Adrian: We're fairly device-agnostic, so we don't push our clients in any one direction or help them make that choice. We don't have very many clients that come to us specifically with, "I want to do iOS, and this is why," or "I want to do Android, and this is why." Sometimes, a client might choose iOS because of the unique features that iOS has, like Touch ID, for one, is kind of a popular feature that people want to integrate. But, Touch ID would be such a small part of the security aspect of their application that I can't say that it's something that I would bring to a client and say, "You have to do iOS because of Touch ID."
Now, on the wearables side, when you start talking about exercise or health integration, things like Apple's HealthKit may be a differentiating factor, for instance, if somebody approached us in the health care space that wanted to expose more patient information, or enhance the relationship between caregivers and the elderly and their extended families who also have input into that patient's life. Or, if your end goal has something to do with a specific wearable, that might steer you into the development of only one platform. Not all of the Android wearables only integrate with Android, but they integrate easier with Android. Likewise, when the Apple watch comes out, it's probably not going to play super nice with Android.
Another aspect might be if your company is completely driven by Google Docs and other Google services. It might be a little easier to integrate on Android, even though those are all on iOS as well. But like I said, we're pretty agnostic when it comes to platforms. The deciding factor usually comes down to budget and timeline. Then you prioritize by perceived end user device space.
Brandon: The platforms usually achieve feature parity pretty quickly. In all, it probably took only a couple months from when RFIDs [radio frequency identification] were announced until was possible to detect and use them on Android. I think there's a bit of a lag, and probably more on iOS. When Android came out with NFC [near-field communication] as a capability, it just wasn't possible on iOS until the last few devices. But, for the most part, they achieve parity really quickly.
For Windows apps, are there any situations you've come across for consumer apps in which the end users are largely Windows phone users?
Adrian: Not yet, but I've had several conversations with prospective clients lately who very much want to do Windows development, especially enterprise users who want single sign-on with active directory and a few other native capabilities that Microsoft provides, primarily on the on premise, or in the cloud information technology environment. That would be strictly due to ease of integration, and not necessarily do to with iOS and Android hardware.
We've been attending conferences lately where the message being piped down is, if you want true enterprise integration, and you want it to be as seamless as possible and easy to support, and you are on a Windows stack, then you should move away from Apple. That was at an industry conference, a specific vertical industry, not at a tech event. So, I'm not sure how fast that message will spread, but I think we'll hear more about it. Windows continues to grow, but with a 4 percent market share, they've got a long way before average users start coming out and saying, "I want Windows."
Mobile App Cost
Can you describe from a top level what some of the key cost drivers are in developing a mobile app?
Sam: One driver is that a lot of times companies will come to us with a database and an application programming interface, and they want to see that injected into a native application so they can carry it with them. In some of these cases, there's little to no documentation on the APIs that these companies have. That really drives up a lot of frustration, time, and money with the application simply because it's similar to flying blind, not knowing where you're going, not certain of all the results you're going to get, given certain input. I would have to put that one on there, toward the top of that list.
Brandon: One key driver in my opinion is user experience, because you're actually touching and physically playing with the application. In mobile's case, user experience is very important, and I don't think many clients really understand the amount of time and effort that it takes to do that well.
Adrian: Integrations with third-party systems generally drive up the cost faster than just doing native development where we have control of the back-end. Many times, we have to use APIs, and if they're not clearly documented, that drives up the cost.
Higher costs can come from deep integration, extra levels of security, or multiple devices that we're going to deploy on. When I say multiple devices, I mean iOS and Android, and then generally a tablet, and possibly even a Web app. Those are some of the things that can increase the total cost of engagement.
Unknowns can come from difficult to explore things like iBeacons or innovations with wearables, or things that aren't fully documented or out in the world yet. I can't say that those necessarily increase the scope of a project, but they can be an indicator of something that could become a problem later.
On the documentation and planning side, that's pretty static. We don't necessarily charge a flat fee, but it pretty much starts at about $5,000, and that engagement provides us a couple of weeks of discovery and planning sessions where we can meet with the client, and get all the ideas out on the table, pare them back and develop a user experience map, roll the UX map into wireframes, and begin conceptualizing the process and the project, in order to give the client a full view of what it will take to get the app built that they want with the budget and timeline. Again, that process starts at around $5,000. Ultimately, we look at it as close to 10 percent of the overall project budget when we start ballparking.
Is the cost of iOS and Android about the same, or is one more expensive than the other to develop?
Sam: I would say that they're roughly the same. They end up averaging out although they may be more difficult in different areas. One of the reasons it's difficult to apply just a straight scale between platforms is that there are things that are trivial on Android that are hard to do on iOS. There are things that are trivial on iOS that are hard to do on Android. So, it really depends on what sort of capability that the client wants but, for the most part, it tends to even out. To give a concrete example, background services is something that are fairly commonplace in Android, and in iOS until a couple of versions ago, it was completely impossible. Even now, it's an extremely limited area of the system. So, if there's something you want to run in the background on iOS, we're probably going to be able to something for you, but it's going to be very limited in capability of the application, or of the service that we're going to be able to build for you.
In terms of the pricing of a project, and how you go about estimating that, and then charging a client?
Adrian: For the most part, we work toward estimates versus actuals, which means we try to base our estimates on past actual work. We also take into account places where we can streamline that process. We use pieces of code or design patterns that we've used previously to limit our budget impact, to make sure we're not reinventing everything every time. In cases where there are not actuals, where we don't have a track record doing a specific part of a project, we work as a group to go through a planning poker exercise, where we can talk about the perceived complexity, and issues that may arise developing a specific piece of a project.
Once we can evaluate the complexity of each individual piece, then we can work as a group to establish hours, with a baseline of, this is the most complex part of this project, and this is the least complex part, and come to some sort of consensus on an estimated number of hours that are going to go into development. We work in an agile fashion, so most of our projects are not fixed bids these days, but we plan them out via a series of sprints, where we organize projects into issues that can be grouped together and developed as one. We regroup at the end of each sprint to plan our next sprint out. So, we're working towards an overall end goal of a set number of hours but, internally, we break it into pieces.
So, you first estimate the total hours, and then bill the client as you go, essentially, to try to meet that estimation?
Adrian: Yes. But, we will do a fixed bid if that's truly what the client wants.
Do you require a minimum budget? Is there a certain cost range within which you typically work?
Adrian: We don't necessarily have a specific minimum. Most of our projects fall in the $50,000 to $100,000 range, but that's not to dismiss somebody who had a $20,000 project. Usually projects in that lower price range end up being a good candidates for our Web development rather than native development. We have also done projects with a considerably higher budget and longer timeline. Our goal is to develop long-term partnerships with our clients.
In terms of your business model, with all of your developers locally based in Fargo, how does that compare to other app development companies from a value and cost perspective?
Adrian: I would say that we fall in line with similar pricings to development companies in the Twin Cities. We are not the most expensive shop in the world. We are definitely not the cheapest. All of our developers are quite seasoned. We have, in the past, had members of much larger organizations in the city on our advisory board. Our pricing is what we feel is competitive with the brick and mortar competition that's in our region.