Clutch spoke with Don Bora, co-founder and principal in technology at Eight Bit Studios, as part of a series of interviews on mobile app cost and platform choice.
Please begin by introducing your company and your role there.
My name is Don Bora. I’m a co-founder and principal in technology at Eight Bit Studios. We do Web application and mobile development for a number of clients, including small, medium, and large clients. When we get a project, we usually hit all three elements, user experience, design, and development, at once. We feel that we are special as far as software services shops go, where we have all three talents represented at the leadership level. We’re able to tightly weave, and tightly integrate, those demands for every single project. We do some of our best work when we’re engaged in all three.
Mobile App Platforms
Can you describe what objectives or parameters a client should define before they select a platform for their mobile app?
It’s really good to look at your market before you decide your product. You should decide who your users are and what your typical user persona is going to be before you start even thinking about your product. Once you’ve done that, you’ll start to get a feel for what platform your customers are on. In the United States, you’ve got a split evenly between iOS and Android. We’re probably looking at a younger market skewing Android, and an older market skewing iPhone, but that’s partially conjecture on my part. The potential target market space should inform the decision to choose one platform or the other.
Given that the U.S. audience is pretty divided between iOS and Android, which one would you lean towards for the client?
That really depends on the client. Usually, the client is already platform biased. They’ve already made up their mind that they’re going to go one platform or another. We try to accommodate that, and we don’t usually enter into that bias choice. Historically, we tend to get more customers that want to build out their iOS products first, and then maybe don’t even get to Android. So, we are very strongly representing in the iOS community.
Our advice to clients: if they want to build for both platforms, pick one and do it first. Then, once you’ve fleshed out all the user experience, design, and functionality issues, you can start figuring out what it’s going to take to build the product on the other platform.
We tend to see significantly higher costs building an Android app. We’ve seen ratios as high as 20 percent to 40 percent to take an existing iOS application and duplicate it, feature for feature, on Android. That primarily has to do with OS and device market fragmentation leading us to ensure the application runs as smoothly on a four-year-old devices as it does on the newest. Taking the increased cost for an Android application build out into account, factoring in the cost efficiencies gained by having built the iOS application first, you will gain cost efficiencies due to the lack of design and user experience refinement typical on any project.
Is it more expensive to build Android first?
Not necessarily. It really depends on the product. If the Android application is using standard Android user interface conventions, the user experience might be less challenging to implement than if you’re replicating an iOS application. iOS makes some very complicated animations and transitions extremely accessible to developers.
Can you give an example from your experience in which a client chose to develop an Android app first, and why they did so?
The Chicago Fire chose Android first. They wanted an app for their fans that showcased their players and some of the merchandise available for purchase at the stadium and online. They wanted to go Android first, so that’s what we did. Apparently, they had done their market research that showed that their fan base is heavily Android. So, that was a clear-cut case where the client knew their audience.
Does Eight Bit Studios develop any mobile Web, cross-platform apps?
Absolutely. A lot of times, we’ll get clients that come in and they don’t know what platform they want to land on. They’ve got a really strong Web presence, and not a whole lot of functional need. What I mean by that is most of your needs for that mobile presence might be marketing and maybe some small content for the user. In that case, you’re not going to have a strong need for a native application. So, we would encourage a client to use their Web platform to develop some mobile responsive layouts, and use that to launch into the mobile area. You can also launch with a native wrapper that brings in the Web content like some of your retail apps, such as The Gap or Nordstrom on iPhone, or you can just rely on your Web presence alone.
Do you develop any Windows apps?
No. We do not. To be honest, I kind of want to. We just do not have any demand for that. The development environment for Windows is really strong, and that’s why I kind of want to get in there and do something. Unfortunately, we’re not being asked to do any of that, and the market’s just not strong enough for us to enter.
Mobile App Cost
What are the key drivers of cost for developing a mobile app?
Any kind of application programming interface or online platform integration is going to drive up cost, for example, an application that has to talk to proprietary APIs that have either been developed by the client or are non-publicly published APIs. For instance, Zillow.com has an API behind a developer agreement. In this case, you may not know what you’re getting into until you agree to the Zillow.com developer terms of service. You have to apply to use it, so it’s considered by us to be somewhat of a proprietary API. In those instances, cost will go up because it’s a very highly specialized development effort. Anytime you’re syncing data that’s not on the device, you basically have to work through API constraints to see what you’re allowed to do, when you’re allowed to do it, how often you’re allowed to do it. Then, you must make sure that the content is truly in sync, and make sure that the most recent content is where it needs to be. In those instances, that’s the most cost hit you’ve going to experience.
If you’ve just got an app that takes advantage of some of the native platform features, like location awareness, orientation, or even the dialing capabilities on the phone, you’re going to be OK. You’re not going to incur a lot of cost because those features of the phone are so baked into the native API that they’re very easy to use. Whenever you’re going off-device, whenever you’re going to a Web API, that’s when you run into cost issues. I would say that’s by and large true.
If you’re doing any highly specialized game development, you’re going to run into some cost as well, but we rarely see that.
What about the research and discovery phase? Can that be costly?
We’re finding more of a need for that as the mobile market matures. We did it for the Field Museum of Natural History in Chicago, and it was a lot of fun. For that kind of thing, you’re basically paying for strategy. So, we do research, and figure out what your personas are, where you market is, and what your competitive analysis looks like. It’s an exciting phase of the process because we can aggressively apply our engineering expertise to inform product development. This ends up being a fixed-cost phase due to the number of hours that will be spent and overall budget concerns. This is, of course, not always the case, but it’s what we’re seeing.
How do you estimate project cost?
For us, it’s important for people to understand that at the top level, the ownership of the Eight Bit Studios, we’re all executors as well; we get our hands dirty. We are directly involved in the projects. We’re a small company, and we’d like to remain small specifically so that we can, at the leadership level, remain involved in our client products. We feel that our clients still want that. They want involvement from my two partners and myself. Because we do that, every project that we bid on we actually estimate. We break them down feature for feature. We estimate on cost across each discipline. We’ve got formulas that we use to figure out what that’s going to cost from a time and budget standpoint.
Are clients billed on a periodic basis?
Exactly. We’re time and materials when we engage in a project. We then run a bi-monthly schedule, so every two weeks invoices go out. They get detailed invoices, and they get weekly status reports.
We take project management very seriously. We’ve experienced that project management can make or break a project, and we have developed internal tools for that. We have an internal status-reporting tool that we’ve developed because all status reports end up so poorly organized. The clients just ignore them, and then they start losing what their project is about. So, we basically developed our own tools to address that specific issue. We’re looking forward to launching it in the fall or the spring. We’re pretty excited about it.
In terms of your business model, how does it compare from a cost and value perspective compared to an outsourcing model or others?
We don’t outsource any of our client work, that’s a strict rule for us. The reason we don’t do that is, between my partners and myself, we’ve been a part of a global team before, or we’ve managed a global team. I’ve managed global teams for startups, and I’ve been on a global team in previous jobs in my career, so I know the pitfalls and I know where the holes can develop for those relationships. When we’re dealing with client projects, people building the product will make hundreds of on-the-fly assumptions to fill in functional holes. Since we’re in very close contact with our clients on a weekly basis and, sometimes, more often, we can fill in the gaps and very quickly and precisely. If we’re using an offshore team, or a team that’s not very tightly integrated with us as a company, we’re going to get it wrong more often than we get it right. We’re not willing to take that risk for our clients.
Now, we have used offshore resources for some of our internal product development for Eight Bit Studios. One of the reasons we do that is to keep abreast with what companies are out there, who’s doing what kind of platform work, and what you need to do to be successful with offshore teams. We have tried many communication and collaboration tools and methodologies because it’s important for us to understand the offshore space. What it comes down to is, if an offshore team doesn’t fully understand the product that they’re building, they will start filling in the assumptions incorrectly.
The best example of this is health care. If you’re building a healthcare platform for a U.S. audience, and your execution team is overseas and doesn’t understand the culture or the nuances of health care in the U.S., they’re going to start making assumptions based on what they know. For instance, office hours might not exist in the Ukraine on the weekends. If you get a Ukrainian team building it, for instance, they might not build that into their platform. Now, all of a sudden, you’ve got an incomplete platform and you have to spend extra money to correct that mistake. So, that’s the kind of thing we’ve seen happen.
Does your company require a minimum budget?
No. We do not. The reason we haven’t done that yet is, when you get to a certain size, you do have to watch what kind of projects you take on because projects are expensive to execute for you, as a company. We remain pretty small mostly because we want to retain that personal connection with our clients. That may change in the future, we may decide that we want to take on bigger and bigger projects, but if you stay small and nimble, and connected to your clients, you have the ability to take on small projects.
We can help a client build a small prototype so they can get their funding, or one to show to their board of directors so they can get approval or something like that. We like being in that game. We like being able to help people prove their idea.