Clutch spoke with Tobias Dengel, CEO of WillowTree, Inc., as part of a series of interviews on mobile app cost and platform choice.
Please begin by introducing your company and your role there.
I'm Tobias Dengel, the CEO of WillowTree, Inc. We are about 80 people and are focused on mobile solutions for our clients. We do native iOS development, Android development, mobile Web, and we develop application programming interfaces and back-end integrations as necessary. We also have a design team here, a strategy team for our clients, and a quality assurance team. What is unique about our approach is that we're really focused on agile, and we feel the best way to achieve agile methodologies and the synergies that come from that approach is to have all our folks in one place. So, our entire company is based in Charlottesville, Va., which gives us great access to a very high-quality talent pool with the University of Virginia in our backyard. At the same time, it keeps our costs in control versus places like New York and the Bay Area of California.
About half of our business is consumer-facing applications, and the other half is internal enterprise applications. We focus on Fortune 500 clients. These companies have a real need to work with a team that has in-depth experience handling large mobile engagements that often involve complex or legacy systems. We focus on apps that serve these companies' internal and external needs that are really mission critical to what they're trying accomplish, such as where it makes sense for them to invest in a custom applications that help them cut costs, if it's an internal app, or help their sales teams increase revenues.
Mobile App Platforms
What are the platform options for a mobile application?
From our perspective, there are really four ways you can approach mobile from a platform standpoint. One way is to develop natively, which means using the tools provided by iOS, Android, or Windows to develop those apps. A second way is to create hybrid apps that are partially native code and partially HTML. Three, you can do all HTML, which really then aren't apps that you're going to have in the app store anymore, but they're mobile websites that users can bookmark on their phone just like they could an app. In many ways, especially for internal apps, that might be the best way to go. Then four is that you can use platforms like PhoneGap or Xamarin to develop one time, and then those apps are then exported into iOS, Android, and others, and then ported to be native, but you're developing them in a single platform. That last solution sounds really good, but it does have tradeoffs, however, because the functionality that you have available to you in those platforms is always behind the functionality that might be available in iOS or Android natively.
What are the objectives or parameters that a client should define before they decide with which platform option to use?
There are a couple things. One is they need to figure out what business problem they're trying to solve, who the users are going to be and what devices those users are going to have. That's obvious, and I think many people do that.
The next thing I think they need to consider is maintenance, and what kind of developers they have internally. They can choose a platform to develop on, like Xamarin, which is a C# platform, because if they have many C# developers internally that may make a lot of sense versus developing in iOS or Android. This would be a good option even if they outsource the design and development of the initial app, which often makes sense because of the expertise working with folks who have launched hundreds of applications. The maintenance plays into it longer term. So, if you have a couple iOS or Android folks, you might want to do a native application. If you have C# folks, you might want to do Xamarin. If you have Web-based folks, you might want to do an app that's largely hybrid, so big chunks of the app are actually HTML, which might be easier for you to support. Or, you might have a strategy of having the app supported externally, then obviously the long-term maintenance and support matters a lot less.
For internal apps, it's usually a device decision. Therefore, if you're equipping your sales force with tablets, the decision whether to give them Android or iOS tablets is obviously going to impact what kind of apps you're going to build. Making those decisions together is what companies usually do, and then they let that be driven obviously by cost of the device. There's cost to the development, and then additional concerns like security, if they think that iOS versus Android is more secure for the application that they're building. So, all these kinds of things come into play when you're trying to decide what platform to use.
For consumer apps, are there certain situations where it's better to start with iOS or better to start with Android?
It depends on the audience. In most cases, unless it's a very unique audience, in the United States, we see about two to three times as much usage on our iOS apps as we do on our Android apps. In certain segments, like lower income segments or younger segments, it might be closer to 50/50, and some segments we've even seen more Android users that iOS. Typically, for most of the apps we're building these days, we're building them concurrently, iOS and Android, because our clients are trying to address as much of the market as possible. Between those two platforms, they're getting around 90 percent right now. On certain projects, we're also developing Windows at the same time.
I think if you've got to pick one platform, we typically recommend iOS, just because it's going to do better out in a consumer-facing environment, unless the app is a prototype kind of test app. Then, we recommend Android. For Android, we don't have to go through an approval process with the App Store, and that approval process can take one to two weeks, and also there are just constraints around that. In Android, we can get something out, and tested, iterate on it, and figure out what consumers want much more quickly.
In what use cases do you find that you're building a Windows app in parallel?
For consumer facing, it's typically if a client really wants to get as much of a market share as possible. Sometimes that applies to, for example, government agencies. They have to try and make whatever they build as ubiquitous as possible. Or, it may be special use cases, where there might be pockets of Windows types of users, which also tend to be younger. So, if they're hitting a demographic like that, a Windows app could be worth it.
Mobile App Cost
What are the key cost drivers in developing a mobile app?
There are lots of drivers of cost. The obvious one is complexity. The more your app does, the more it's going to cost. The other driver is how it's going to integrate with your back-end system, how it's going to get data and display data on the mobile device. The third is how custom you want your app. Our business is based around clients who typically want a very custom experience, clients like the NCAA, HBO, NBA, or Valpak. Those are all the types of clients for which it's really important to their business that the apps are unique and are part of their brand positioning, and they don't look like cookie-cutter apps that use Apple's or Android's out-of-the-box building blocks. Then, there are other factors, too. In terms of security, how much encryption are we doing? Are payments involved? As you go down the feature list, any one of those adds cost and complexity.
Can you describe a little bit about maintenance costs? Is there a certain percentage that you can think about adding on to the initial development costs to estimate the maintenance costs?
It really depends on the project. One of the things we're big on is an agile approach, whereas if you talked to us two or three years ago, we would just have a giant project. We would launch an app, and then we'd say it's going to cost 10 percent to 20 percent of the build to maintain the app for the next year or two. What we're doing now is, we're going to an agile process, where we say, "We're going to have a team of this many people for the initial build, and then we will launch what we have at the end of that." Then, we'll iterate with a smaller team, let's say half that team, for the next three to six months. Then, we might shrink that team even more. It's all based on how big the team is going to be for an extended amount of time, with the knowledge that app projects are never over for the kind of apps we're building. For mission critical apps, the app is a living thing. There are always going to be changes, there are always going to be improvements. The app is a critical part of something that the company's doing.
So, we typically don't do the kind of projects where someone just does an app and puts it up, and then goes back to it once every six or 12 months and does a little maintenance on it. These are apps that are absolutely critical. They might be the main app that a sales force uses to pitch clients for a big pharmaceutical company. For that app, someone's going to be doing something on that app 24/7. Those apps are always being maintained and always updated. So, to us, this concept of build and then maintenance is kind of going away. It's really a total cost of ownership and total cost of ongoing support of these apps, which might be 50 percent or 75 percent of the initial build of the app. Instead of saying, "This app costs $250,000 to build, and then $25,000 a year to maintain," we would say something like, "This app project is $150,000 a year for three years." That's how we would look at it.
How do you go about actually pricing a project and then charging clients?
Most of our projects end up being in a fixed price scenario at the end. What goes into that is obviously the amount of time. We measure this in sprints, which are one- to two-week periods of time that our developers will put against a project. The time that we spend might be less than a competitor's time because of either the skill set of our team or the software tools and accelerators we have that allow us to create, test, and develop code more effectively than a freelancer, or a lot of the offshore companies. All of that gets tied together, and then we would typically put a bid in on a project given a certain scope.
The billing on that, depending on the client, is either based on how many actual humans are put against it in a given period of time, such as per month or, more commonly, they'll be milestone payments. It's going to be this much to get started, or at the end of the first design phase. Here's how much on final designs. Here's how much at the alpha delivery, beta delivery, and then some sort of monthly or quarterly amount for the ongoing upkeep of the app.
How do you estimate how many sprints you'll need and how long the project will take?
Typically, we start by creating a mind node. Essentially, we take a project and break it down into lots of component parts. It could be the screen level, and it might be less than the screen level, it might be components that impact multiple screens, like a certain type of login. We basically try to break everything down into small parts. After that we say, "How many of these parts can we fit into a given sprint?" We'd take a look at our resources to figure it out and say, "Alright, we can put four of these into one sprint, and then we'll do seven in another sprint. We can do one in the next sprint." That gives us an estimate of the amount of time it's going to take to build the app.
Is there a minimum budget that WillowTree requires for a new client?
Yes. For a full app development and deployment, there is almost nothing we do these days that's less than $50,000. We can do strategy work or prototyping work for less than that. Sometimes, a client comes to us and says, "Hey, we need a strategy to enter this market. We want to see what other apps are out there, and what you guys think you can do better." We might charge them $10,000 to $30,000 for that, depending on what it is. Or they say, "We're looking at one feature and we don't know if it's going to work in iOS. Can you guys do some prototyping work for us?" So, that again might be $10,000 to $30,000, but for a full deployment, there's almost nothing we do less than $50,000. Now the bulk of our projects are more than $100,000.
In terms of your business model, being a local team where everyone's in-house, how do you think that compares to an offshore model, or a globally integrated model? How does that compare from a cost and value perspective?
Our goal as a business and our positioning is to develop best-in-class mobile experiences at a reasonable price. Reasonable doesn't mean lowest. We are going to be higher priced in some ways than offshore, but we'll be lower priced than big integrated firms or agencies in New York, San Francisco, or Los Angeles. We also believe that cost shouldn't be driven by hourly rates. The best mobile designers and developers produce 10 times or 100 times at the level of a poor designer or developer. Valuing what designers and developers do on an hourly basis is something we take issue with because an hour isn't an hour. It's not apples and apples. One of our developers might be able to produce five, 10, or a 100 times what another developer might be able to produce, but that's not reflected in the hourly cost.
With all that said, we think it's really important for clients to look at the total cost of ownership. They've got to look at what it costs to build this app in an absolute total amount, and what it's going to cost them to maintain this app during the next one or two years. That's how you should be judging it. If I were a company looking to start a major mobile project, I would narrow down the list of folks I think could to the job, and then create a request for proposal. Planning out a good RFP is really essential when it comes to selecting the company you work with. In fact, we think it's important enough that we have a checklist for creating a mobile RFP on our website that anyone can get for free. Create the RFP, and then compare total price. Price per hour would be largely irrelevant to me; what would matter most, as I see it, is the total cost and quality of the product I'm going to get at the end of the project.