Clutch spoke with the Worry Free Labs team as part of a series of interviews on mobile app cost and platform choice. Paul Choi (CEO), David Issa (CXO), and Thadd Selden (CTO) shared their thoughts with us.
Please begin by introducing Worry Free Labs.
Paul Choi (CEO): Worry Free Labs is a mobile design and development agency. We're really focused on helping our clients with innovation. We try to push the envelope in design and development, so that we're creating a unique product that no one has done before and that's new to the market. That's really what we're known for. We have a very strong foundation in design and software engineering, and have added a lot of design and engineering talent and capabilities during the last couple of years. We are a full-service company. We're based here in New York City, but we do have offices in Atlanta and Nashville, and we have some of our team members on the West Coast, too.
Mobile App Platforms
In terms of mobile application platform selection, whether you're going with native, hybrid, or mobile Web, what objectives or parameters should a client define before they select a platform?
David Issa (CXO): I'm the chief experience officer with Worry Free Labs. There are several factors that I think would go into the technical approach that we would recommend for our clients. At the very basic level, depending on what the app does, understanding what their target market is, and then understanding where those target markets live within the different app ecosystems. The iPhone population can look very different from the Windows mobile population, which looks very different from the Android. So, understanding the demographic that you're going after from a business side is very important.
After that, understanding the needs you have for the application. If your app idea has geolocation items or features that require native capabilities, then that's going to prompt one suggestion rather than another. Then, last but not least, it's also understanding if this is an enterprise app or a consumer based app.
Paul: I think budget is also a consideration here as well. We'll make recommendations depending on the budget. We also want to understand the user experience that the application is going for. If it's a consumer-grade application, we typically recommend native rather than hybrid.
Thadd Selden (CTO): Another note to add as well is that there is also a bit of user profiling as to whether or not they would actually install the app. That's going to be a major factor in terms of looking at how your users are going to adopt it. This ties into bigger question of mobile Web versus a native approach, where a native approach is an app that gets installed versus just a mobile website that you go to. There's a difference of whether or not your user base is going to be just browsing and needing to do something, or is it someone who's continually going to come back to the app to perform specific tasks.
Then, of course, you have to consider the technology side of it. When you look at what your app is trying to do, can you do that through the browser? Within the install base, you then have two categories: native and hybrid, which is the idea of the write once and run anywhere. You're writing a single code base that is used on both Android, iOS, and potentially Windows as well, versus doing a pure native solution.
When making that decision [of native versus hybrid], you have to look primarily at two factors. One is the technology. Can the hybrid tool kits do what you need them to do? Do they have the level of camera interaction? Do they provide the type of geolocation that you need? Can they do notifications the way that you want to? Then, more importantly and to Paul's earlier point, from a user experience standpoint, can you make your app work the way that is going to provide your users the best user experience, using something that is somewhat more generic? So, those are the two real drivers on the hybrid versus native approach.
From your experience, can you share any examples that depict good use cases for a hybrid or a native implementation, and why that approach was chosen?
Paul: I would say that the majority of the apps that we've developed and designed are native, the reason being that a lot of the apps we have done are consumer apps. So, the user experience requires them to go native versus a hybrid approach. For example, we designed and built the KeyMe application, and that was built natively in iOS. That app has performed very well, and it's been successful. I think part of the reason is that it was built natively for iOS, and the performance has been very good. I think it uses some pretty complex technologies.
Thadd: Yes, I would argue the KeyMe would be very difficult to do with a hybrid approach because of the level of camera interaction and things like that that are required.
Paul: Exactly. One app that works well for hybrid is the Walgreens application. This application was made with a hybrid approach because of what it does. It crosses a little bit better to iOS and Android because they have an existing Web application that was pretty easily portable into a mobile application. It's a consumer application, but I would say it's a business-to-business application as well. So, I think the audience there lends itself a little better to a hybrid approach versus some of the other apps that we've done.
In terms of native apps, looking at iOS versus Android, are there differences in terms of technical capabilities that would play into your platform selection?
Thadd: Yes. There are certainly technical considerations. The iOS App Store policies are much more stringent than those for Android, so that's a major consideration. If you're doing something that's got some complex e-commerce, that needs to get certain user information that the App Store policies would prevent you from getting, that's going to be a consideration. From a technical perspective, anything that you need to do that requires real persistence, sometimes will be very difficult to do on iOS. We've had apps that need to do constant tracking and location awareness, and those are things that, from a technical perspective, you just can't do on iOS. There are also things that happen at a system level. If you wanted to build an app that implemented some type of parental controls or something like that, you can't do that on iOS, but you could on Android.
Paul: To add to that, I think some of the rationale behind whether to choose iOS or Android, from a technical perspective, is the amount of devices and operating systems on Android, and diversity of users on different operating systems. That's another consideration.
Thadd: One other thing along those lines is also distribution method. We have an app that goes out to charter schools, and they control the whole chain of distribution. That is often easier to do on Android, and cheaper when they have full control of the hardware and the distribution.
Paul: If the app is going to do some type of in-app purchasing, that's a big consideration as well. The stats are good for iOS making purchases, but also, if it's an Apple in-app purchase, Apple takes a pretty big percentage of the purchase as well. So, that needs to be considered.
Mobile App Cost
What are the key drivers of cost in developing a mobile app?
Paul: One main driver is the complexity of the application that's being built. [This includes] how complex the interactions are, whether there's a big back-end system that's required to store and handle all the data, and the amount of screens that are going to be required.
David: Some of the things that really end up driving up the planning and design costs are how bleeding edge is the idea is, or how much innovation will really need to happen upfront. There are a lot of app ideas that are fairly straightforward and basic. We can get through the planning and design a lot quicker for those than those ideas that are more loosely defined and need more brainstorming and innovation around them.
There are two main reasons for this. One is, when you're innovating a brand concept or something that is really cutting edge, you have to involve the cross-functional teams a lot more. Designers and developers need to sit in the room together and really push one another to understand both the limits of the technologies, and how to work around them to break through some barriers. The other factor that comes into this is when you're vetting new ideas that haven't been tested, you don't have any existing market research that's out there. So, rapid prototyping, user testing, and iterations on the design side become much more important, and you want more rounds to do that.
Paul: From a platform perspective, we really focus on iOS and Android. We have typically experienced that Android requires a little bit more time and cost than iOS. What we've seen from the projects that we've worked on is that, because of the amount of different screen sizes, devices and operating systems, it's a little bit more costly to build an Android app than an iOS app.
David: To add to that, the flexibility that Android offers you adds complexity to the development process. So, Android does tend to cost a little bit more, but you do have more options in how you go about developing the app.
Thadd: There are a lot of factors that can have really significant cost effects for seemingly small things. There are little things that seem obvious, that end up costing a lot more. A good example is any type of payment processing on an iOS app, outside the in-app payment process. If you need to integrate the ability for someone to enter a credit card, set up a recurring payment, or anything like that, you're talking about a major addition of time and money to build that out.
Also, the amount of back-end infrastructure you need is a cost driver. There are virtually no apps that exist in a vacuum. Almost all are interacting with a Web service application programming interface of some kind, and usually that's going to be developed in conjunction with the app. Some Web services are as simple as providing an administrative back-end for the app owners to do things like help you reset your password or things like that. Others are the other end of the spectrum, where you're providing a full Web app that gives you some of the same functionality of your native app, so that they can still interact with it off-device, or from another place. So, the scope of that, the size of that API, and the number of communications that need to go back and forth, can be a major driver of cost.
David: Then, on the features front, obviously the more features that are included in the app, the more cost gets driven up. That being said, not all features are created equal. I think one of the most expensive features that people often request, and don't really understand the complexity behind, in addition to the payment processing, is notifications that need to be handled or pushed to the device. So, sometimes the more complex the feature, the more that can drive the cost.
Paul: Depending on what scale and how many users the app is going to be supporting, that will drive up your recurring monthly cost as well. If you use a service provider like AWS or have your own in-house hosting, that can potentially drive up ongoing costs.
Do you typically provide ongoing support and maintenance for the apps you build?
Paul: We support our clients in any way they need us. If a client does not want to hire an in-house team to support the app, we will support the app. What we do is a monthly maintenance contract to maintain the app and do any updates or upgrades as needed. More often than not, the app companies we're dealing with will either hire an in-house developer, or have an in-house team at some point, if they don't already have one. There are a lot of updates that need to happen, bugs that come up, and new versions of operating systems. So, in the app world, the work is never done. It's really constant, so we definitely support clients in that way, but more often than not they end up hiring internal resources to maintain the app at some point.
Do you have a minimum budget for projects? What is your typical project size?
Paul: We don't have a hard minimum budget because we also do design-only projects. I would say a minimum for a design project would be around $25,000. For design and development, typically we wouldn't take on a project smaller than $100,000, and that's going to be a pretty simple application. Our typical projects are in the $150,000 to $300,000 plus range for a mobile app and a complex back-end system can add significantly to that cost.
How do you go about estimating project cost?
Paul: I would say this is more art than science. There are a couple of things we do. We get all the requirements first. We try to understand the technology involved. We'll do a separate design deep dive and estimation. We often compare the cost it took us to do similar applications in the past. I would say that design is a lot easier process to estimate than development because it's a lot easier to replicate, or to look back historically and determine what was done in the past for similar applications. For development, it's a lot harder.
Thadd: We involve our developers throughout the discovery process, so they have a really good idea. We try to come up with a ballpark idea before we sign the project, and that's going to be based on comparison to historical projects and analysis of the core features of the app that we know at that time. Then, after discovery is complete, which is the process of really sitting down with our user experience folks and trying to understand what the app's going to do and how it's going to do it, our development team will refine that and come up with a much better breakdown of how long everything is going to take.
Paul: To summarize, we really try to determine how long we think the application will take to build and how many resources are needed for the project. It's a combination of how many man hours, and then how many resources would be available to work on that project. We also try to assign a rating of complexity on the features and functionality. If it's a three, it's very complex. If it's two, it's mildly complex. If it's one, we think it's pretty straightforward. That will vary our time estimates as well. So, we try to do as much diligence upfront, but ultimately we really want the design process to be free flowing and creative. So, we try not to limit what's done in design. After design, we definitely have a much clearer blueprint of the application that's being built. The development estimate is a lot clearer after the design phase.
Do you normally work for a fixed price or bill time and materials?
Paul: We do not really do fixed price projects. We do time and materials based. We try to keep our projects within that estimate, but sometimes clients will change directions or the scope will change. So, it's typically better for both us and the client if we work on a time and materials basis, and that's what we do. It gives both parties more flexibility.
In terms of your business model, how does that compare to other development options, such as offshore, globally integrated, freelance, or in-house team?
Paul: We try to give clients great value through our work and our services. From a competitive perspective, we are on a lower priced hourly rate than some of what we would call our competitors. I think what allows us to do that is that we not only have developers here in New York, we have developers in less costly cities like Nashville, Atlanta, Sacramento, and Seattle. That allows us to pass on those savings to our clients. So, I think our model works well for a lot of clients here in New York because they're getting New York quality firm, but with a slight discount to what we'd say our competitors would give.
David: I want to emphasize, too, that we are a design shop, so that means we're working with our clients to do more than just build something. We're strategizing with them. We're trying to make sure that they're positioned correctly, and then letting those factors drive the design and the features or needs of the application. There are many offshore teams, and companies like that, that are strictly development shops. They will provide you a team of engineers who will do exactly what you say. We look at it as part of our job to push back when we think a client is heading in the wrong direction. In many ways, we are consultants in that regard.