Clutch spoke with Gavin Fraser, founder and CEO of Small Planet Digital, as part of a series of interviews on mobile app cost and platform choice.
Please begin by introducing Small Planet Digital and your role at the company.
My name is Gavin Fraser and I'm the founder and CEO of Small Planet Digital. We are an agency located in Brooklyn, N.Y., that employs 24 staff members full time. We specialize in making native mobile applications, specifically iOS and Android applications, for clients. We've been in business for more than five years now. We have more than 60 published applications that we've developed, many for the consumer market, but also many for distribution and use internally at organizations and companies.
We have developed in many different verticals. We have a big portfolio of children's apps and games for clients like Disney and General Motors, but we also have educational apps that have been distributed in middle schools. We have retail applications that we've developed for clients like Oakley and Fujifilm. We have medical applications that we've done for the University of North Carolina that are used in clinical studies. Recently, we've been doing some real estate apps. So, we really tackle a broad spectrum of work in terms of design and function.
Mobile App Platforms
Before a client decides whether to develop an app on iOS, Android, or another platform, what are the objectives and parameters they need to define?
In terms of what the business purpose of the app is, we can put apps into a number of buckets. One is our consumer-facing apps where the goal may be monetization, so that would include games, children's book apps, or other types of publisher-content type apps. In that case, generally speaking, we almost always are going to go iOS first. For the last few years, it's been a clearly more monetizable audience, especially here in the United States, but globally as well. I believe the numbers are five times in terms of monetization with iOS versus Android. So, if you're looking to make an app that is designed to make money from consumers, then we almost universally see iOS as the first stop there, and then maybe a stop into Android at some later point in time.
Contrast that with a retailer's app, which is really more a utility or added-value app targeted to consumers, nothing that they're going to pay for, but it's going to improve their relationship with a brand or their shopping experience. Sometimes, those audiences that we're reaching out to skew more to the Android side than the iOS side, so it really comes down to who your audience is and your distribution parameters. Is this for the U.S. only? Is it global?
Do you normally begin with iOS or Android?
We almost always start with iOS. We have in the very rare occasion developed an Android only app. That is exceedingly rare. It is not rare at all to do an iOS-only application. When you're doing a cross-platform application, which is the most common for our clients, we always start with iOS. There are whole blog posts behind why that is the case, but basically it's faster, it's a more controlled development environment with better tools for developers, so if you're going to start in Android, you're actually going to spend more money. Also, a critical part is the testing and quality assurance of an application. On the iOS platform, different device types are proliferating, and we've seen that most recently with the iPhone 6 and especially the iPhone 6 Plus now. So, it is getting a little bit more to deal with in terms of devices. But, for the most part, Apple has created a finite universe of hardware and software. There are more people using the latest software in iOS than in the Android world. All of that contributes to a much more focused and streamlined QA process. QA takes time and, therefore, money. That's one of the reasons why we go iOS first. Add to that to the fact that most of the consumers our clients are targeting go after iOS first.Then, after we've designed and built for iOS, we turn to Android, and it becomes more of a straightforward porting exercise. There may be some features that don't apply, but not typically. Usually, developing the Android app takes about half the time that we spent concepting, designing, developing, and launching the iOS app. You don't have to do the concept and design iterations anymore, and you already know what the features are, so you just code it and test it.
Are there any exceptional cases where Android first or Android only is the best option?
Android is far more relevant right now to our clients than it was even a year or two ago. We used to get approached by clients who would come in saying they want to be on iOS and Android. We'd explain the schedule and budget implications of that decision, be it a good decision or not, and most of the time, the clients would just say, "Let's just scrap Android and we'll do iOS and maybe get back to Android later." Now, not doing Android is increasingly not an option for anybody, and that makes sense.
There are a ton of people out there in the world with Android devices, far more than with iOS devices. If you are going global with your application, especially on the enterprise side of things, if we're making an application that's going to be deployed across a multinational company to sales reps in Germany, Indonesia, and South America, it better be on Android. So, there are many cases where it's not an option not to do Android, and increasingly that's the case.Now, for Android first and only-Android apps, that's usually a very specific business case. The case I'm thinking of in our experience was a company that was going to distribute tablet applications privately, and they had partnered with a tablet maker that was making Android-based tablets. So, they were actually deploying hardware and software in the field, and the hardware side of the equation had already been determined to be an Android device, so that's why we made an Android app for that.
Does Small Planet Digital do any mobile Web or hybrid applications?
When it comes to mobile Web, we tend to serve Web pages or Web views in our natively coded applications. We don't typically just create a pure mobile optimized website, we don't see users or clients valuing those experiences as much as natively built apps.
I think that debate was pretty lively about two or three years ago. Should we go mobile Web or native app? In the opinion of users out there, and just looking at analytics and what people want and how they're behaving on their devices, native applications are it. Some clients will want to just make it once and service everyone through the Web and save a bunch of time and money. Well, I guess you could, but in almost all cases, you're going to end up with a relatively poor user experience compared to a natively delivered mobile application. The recent example of Facebook's dive into mobile is textbook. They went with a mobile Web app at first, and realized it was a tremendously bad decision from a user experience standpoint, and scrapped it. Now they have native applications. Users don't want the mobile Web. Users want really high performing, snappy, natively coded applications. So, no, we don't build a lot of mobile websites.
Are there any optimal use cases for hybrid apps: mobile Web components wrapped in a native container?
They can be good for serving up refreshed content. There may be a newsreader or newsfeed sending some sort of content or media to be consumed. That's the case we see most often. But, if you're going to have any kind of snappy interactivity or interactive elements, then you're probably going to want to code that natively.
Does Small Planet Digital make Windows apps?
No. We never have. Not many folks are asking us for a Windows app. Windows Phone and Blackberry are, from where we sit, pretty irrelevant at this point. iOS and Android are it.
Mobile App Cost
Can you describe the key drivers of cost for developing a mobile app?
The clients we work for are usually pretty sizeable. Any kind of quality application that is going to be applicable to these businesses is going to price out at hundreds of thousands of dollars at a minimum. Usually smaller companies, and even larger companies sometimes, don't have the budgets to tackle these projects properly.
No two apps are really the same. We can be making an app for Disney or we can be making a sales tool for Oakley or a consumer-facing app for the NPD Group, and those are three completely different audiences, products, and user experiences. But, there are some things that they all have in common that are going to drive time and budget.
The biggest driver is the conversation we were just having. Is it cross-platform or not? So, are you doing an iOS and Android application or just one of the two? Some are easier to go cross-platform than others. For example, I would point to our experiential apps, for instance the Disney storybook apps that we make. Two recent ones that are doing well in the store right now are Frozen Storybook Deluxe and Disney Princess Palace Pets. These are fun, animated, light activity and game applications. They are not your standard kind of universal interface kit experience. These experiential apps are actually cheaper than most to go cross platform because we can use certain tools and platforms in the development of those. The most commercially accepted way to do it right now is a platform called Unity. We have our own platform as well, PlanetX, that allows you to go across platforms a lot more easily.
Another driver that's pretty obvious is, what's the feature set of the app? Is it doing a whole bunch of things? We are often, almost always, talking our clients out of features and functionality. There's a temptation when a lot of stakeholders get involved for everyone to want their favorite feature in there, and some of the real work involved is how we can make this app experience as streamlined and rewarding to users as possible. We, at Small Planet, look at everything through that filter of the user. The user is king, and we need to make sure it's a great app experience for that user and add value and do something that the user will want to come back and do again.Another driver to consider is, is this an app that is going to have dynamically updated content? Or, is it going to be a standalone release type of application? Those have long-term and short-term implications. If you're going to do an app that you're just going to release to the marketplace and the plan really isn't to update it much, an example might be our Esquire Hardest Puzzle Ever app that was a game, or even more recently our NPD Group Receipt Pal app. Once it's out there and launched, there isn't too much you need to do to keep it up to date other than really pay attention to any iOS or Android operating system upgrades. If you're happy with the functionality that it's presenting to consumers and consumers are happy with their experience, fine. There isn't really a lot to do afterward. There's wasn't a big back-end that we had to develop. It already existed at our client and we were able to just kind of tap into that.
But, for other apps, once it's out there, you are going to be breathing new energy into it constantly and new content into it. Maybe it means you are working the back-end, like with current events-based article readers, or maybe you're adding new features and functionality, maybe it's a game and you're adding new levels to it. Maybe it's a Salesforce app and you just want to keep populating it with the latest product information and the new releases and things. Then, part of the original project is going to be really looking at the work flows around that and creating a backend that will allow for that. Not so much keeping the app itself updated with new code but more just understanding there is work to do behind the scenes to keep it fresh and alive. The need to modify or create new content on an ongoing basis to keep the app fresh is going to be a cost driver.
What are some other lesser known aspects to consider about cost?
Maybe smaller things, but things you definitely need to consider, include whether the app is on a phone and tablet, or is just a phone or just a tablet. There is time and effort that goes into considering the different form factors, capabilities, and resolution of phones and tablets. Another simple one is screen orientation. Can the app live perfectly fine in portrait orientation, or does it also need to resonate in landscape orientation? Designing something well in two different orientations is a real consideration and will affect how you approach laying out the content and the design and user experience questions. So, the answer to a question like that can have cost and schedule implications.
Another driver, not as huge, but to be considered: Is this app going to be localized? In other words, do we have to make the app in numerous languages or consider cultural differences? Our Disney apps are delivered sometimes in eight languages. It's not a massive amount of work, but it's something to consider and it affects your design. German is about 35 percent longer than English, and if you're going to put a word in a button on a screen, well, the button size better be able to accommodate German. Also, we have to come up with the user interface for changing languages between English, German, French, and more and where does that live? Also, device detection: understanding what your device's native language is. None of that is complex, but if you have to do it, well you have to do it. It takes a little time and therefore money.Other small considerations include whether you are going to include analytics in your app or not. That's usually just implementing a code library. It's not really the development cost of doing that, but it's more the strategic cost of doing that, of deciding what you want to measure. It may be completely obvious but, sometimes, that's a tough question of what are we going to measure and what are we going to do with it. It adds a little bit more strategic thinking time to a project.
Another cost driver that is related to app development is the marketing plan for the app. That's huge. Marketing the app can easily cost as much as it costs to make the app.
Does Small Planet Digital often work with clients on marketing their apps?
We definitely help all of our clients in marketing to some extent. We're not out there planning media buys and marketing campaigns as a core offering, but we're most certainly helping in this area. Most of our clients will have their own marketing channels that they're comfortable with or their own public relations agencies. That's not our core business, but we will certainly do our part on the app development side if it's relevant, making sure the app has the proper tie-ins to social media, and helping getting it noticed in the right spots.
We do help our clients by doing our own grassroots kind of guerrilla marketing for an application. We most definitely help get the application noticed by Apple and by Google, who we have longstanding working relationships with.
Often, the best thing you can do is to provide another avenue or a path of introduction to the good people at Apple and the good folks at Google, and say, "We have this great client and you know us, we're Small Planet, the developers," and they do know us, which is good. It gets on their radar a little bit easier, and that can be a big help in terms of getting real estate on the App Store or Google Play, and getting some sort of editorial consideration and placement. Google and Apple will give us constructive feedback and ideas for making the app resonate even more, and we often act on that advice. That can make a really big difference, so we help all our clients do that.
Another thing we do generally is submit apps for award consideration and contests. We've gotten a bunch of awards, so that's always fun for the team and the clients. It's just another of the little things to get it out there and get it noticed.Another thing that we have done on behalf of clients is managing their Facebook ad campaigns. It's pretty incredible and it's super powerful.
I would also put submitting your app to the App Store or Google Play in a well-done way in the marketing bucket. The copy, screenshots, and app icon are all pieces that consumers are going to look at and that affect your app.
I'd also call post-launch monitoring of the app a bit of marketing as well. You're going to see user reviews and, sometimes, the user comments are really great and useful and give us an idea for a new feature. Or, maybe the haters are going to hate. But, sometimes, it's useful feedback, especially if we didn't catch a bug, and we can fix it and respond back to the consumer, let them know we're listening and that we care. Getting those reviews to be more positive will affect the marketing of your application.
Is there a minimum or typical budget with which you work?
We don't have a minimum budget. If someone has a compelling business idea or if it's just something we really want to do, we're going to do it. But, those are the exceptions, I'd say, when we do things that are less than about $250,000. Have we done them? Yes, of course. We're doing a project right now because it's in a vertical that we haven't been in before. We're getting some exposure to a certain industry, and that makes sense for us as a business because we've wanted to be in this vertical for a while, so we're taking a small but exciting project. Often, it makes good business sense to do smaller projects for that reason, to increase Small Planet's brand presence and awareness in a certain community.
Also, a smaller project could lead to a particularly interesting technical challenge. For example, we did a project where we married a GoPro camera with an Oakley Airwave Snow Goggle. It's a heads-up-display [HUD] that's controlled by a wearable on your wrist. It was this mashup of technologies that there was no blueprint for when we were brought into those conversations. No one had ever done it before, so we were really excited to get into the HUD and wearables space, and that was certainly not a $250,000 project. It was significantly less than that. It was about a month of work for a couple of developers and a designer, but we jumped at the opportunity to do a project like that. Fun stuff.
That being said, we keep the lights on and keep the company on acceptably strong financial footing by charging fair rates for the work that we do. Most of our projects are four months plus. Some are nine months long or longer. That includes concepting and design, all the user experience, all the coding, and then going cross-platform, and so you're talking about a team of five or six people minimum working on something from four to nine months. Budgets are more typically $400,000 to $600,000 to put out the first version of iOS and Android.
On a few occasions we've been brought in by larger advertising and digital agencies here in New York to assist and consult on some of their mobile projects, and based on those experiences and a few of our own we can say that there are definitely clients out there paying seven figures for good mobile applications. The knee-jerk reaction may be that budgets like those are outrageous but, in truth, they are not. Given the time and energy involved, and how critical mobile is to these businesses, it's what they should be spending to ensure top-shelf, successful applications. How much does a good TV spot cost all-in? You're going to bemoan the cost of a great app? I scratch my head on that one sometimes.
How do you go about pricing and charging clients?
All of our projects are fixed price projects, based on our projection of personnel and work hours. We have an hourly rate that we assign to people, and estimate the time the project will take.
We will often price out an initial discovery and project definition phase that will last anywhere from four to six weeks. We'll say, "Here are the four people that are going to be working on that and what they're going to be doing. Here are the deliverables of that Discovery phase." During this phase, we're getting up to speed on their business. We are learning what the goals of the application are, what the value add for the user is, what the features and functionality the app needs to have, coming up with initial wireframe/storyboard for the application, and coming up with a rough blueprint. We'll have a pretty darn good idea by the end of our discovery phase of what it is we're designing and building and, at that point, we can then put another budget and schedule together for the meat of the project.
Before we start anything, though, we will give initial guidance of the whole thing so that a client isn't caught in a surprising position where they say, "Wow. I didn't know it was going to cost that many hundreds of thousands of dollars." We're very clear up front with our clients on what we think the project is going to cost. Then, after that four- to six-week discovery period, we offer the project's fixed price, a project budget and a schedule for the apps.
Nobody that is credible is able to offer a fixed price and know exactly what they're going to build on day one, and it's bad business if they say they can. So, we look for a bit of flexibility on our client's side and in ourselves in terms of how robust certain features are and what features may or may not be in the pecking order of priority, so for some flexibility in terms of the feature set and scope of the assignment along the way.
We're going to get most everything, and maybe we'll get even more than we thought done, but what's not going to change on our projects is the timeline or the budget. What we look for in a good, enlightened client is a little bit of wiggle room on the feature set, or the depths at which we develop each feature. At the end of the day, we're going to deliver a tremendously great app that everyone is thrilled with. We promise. But, we look for a little flexibility in terms of scope and feature prioritization, and that way we can stick to a schedule and a budget.
Our budgets are based on hours, hourly rates, and people. We're completely transparent about how we get there with all of our clients. We use a Microsoft Excel spreadsheet where we show them who and how many hours and all that.We will issue a change order on the project if there's a material change in the scope of work such as adding a whole new and robust feature or if, for example, the client said they were going to build the back-end but now they've decided to have Small Planet build the back-end for them, something big like that. If there's a fairly significant shift in the scope of the work, then yes, we'll change the fixed price, but for the everyday kind of decision making and little changes throughout, we're just going to accommodate those and stick to our fixed price.
How does your business model, with all of your staff centrally located in New York, compare to other models in terms of cost and value?
I do believe that our business model positively affects both cost and value, that it is a win-win situation. Hourly rates offshore are going to be less. Can you get something built for less offshore? Sure. Is it going to be a piece of software that your users are going to embrace, love, and everyone is going to feel like that was a real success? We've never seen that. Never.
We have had several clients come to us after going down that path and say we just threw X amount of dollars down the drain because this app isn't really what we want. We've helped rebuild from scratch some of those same projects, and they've turned into great successes for our clients.
The benefit of what we have here is, first of all, I think we can be just as fast or faster to market than anybody because we have everything under one roof. We have a team of really smart and talented people who have delivered apps together for years, and really work well together.
We have a process that has been repeated with different clients and different apps and that lends itself to speed and quality. We've had 25 App Store category No. 1s for our consumer apps. That's across multiple categories, such as entertainment, news, lifestyle, books, utilities, kids, and games. We won the 2013 Communication Arts Interactive Annual Award for one of our applications, Dragon Brush.
We get very high marks in terms of the quality of the work that we do, so we'll stack ourselves up against anybody when it comes to developing really world-class user experiences. If you're a brand that cares about that and that really wants to deliver the best experience you can for the end users of your application, well there's your value proposition right there.
So, we think we're both fast and deliver high-quality apps, for a fair price. Why wouldn't you come work with us?