Interview with Blue Whale Apps

Please begin by introducing your company and your role there.

The name of the company is Blue Whale Apps. I'm Gregg Weiss, the CEO and founder. 

Our understanding is that Blue Whale Apps only makes native applications. Is that correct? 

Correct. 

What objectives or parameters should a client define before they decide on a mobile app platform?

It really depends if you're planning on building natively or cross-platform. Much of it depends on budget as well. In my experience, we've always done iOS first, even if a client comes to us and says they want both iOS and Android. In that case, they may want to go cross-platform and do an HTML5 app, but if they want two native apps, they will typically start with iOS in order to prove the market and prove their assumptions. Maybe in the second iteration of the iOS app, they will then start the Android version in parallel. I can't remember one app during the last five-plus years that we've started with just Android.

Why is iPhone a more popular starting point? 

It's an easier platform to develop for. The tools are much better from a development perspective. There are also fragmentation issues with Android. In the Apple keynote last week [in October 2014], there was a slide where they said 94 percent of iOS users are on iOS 7 and iOS 8 combined. You've got 48 percent of people on iOS 8, an operating system that just came out weeks ago. In contrast, 25 percent of Android users are on KitKat, which is from 2011. Approximately 50 percent are on Jelly Bean from 2012, and you've got some people that are on even older ones. So, in terms of supporting the operating systems, on the Android side it just makes development and testing longer. Then, of course, we're just talking about operating systems, not to mention the different carriers, screen sizes, and manufacturers of Android devices. There's really something to be said about Apple's integrated approach of hardware and software in terms of development.

Does Blue Whale Apps typically work with American clients?

Typically, yes. I think we've only had one customer that's been overseas. Our clients are primarily based in the United States, but that's not to say that the apps that we build aren't available in every country, which is typically the case. 

Can you give a couple of examples from your experience to illustrate the cost of a mobile app?

Yes. I can tell you sort of higher cost versus lower cost. We developed a golf instruction iOS app that was on the lower price end, although it was a universal iPhone and iPad app. But, there was really no server side, no social features, and no login. It was basically a bunch of videos with in-app purchases. So, in terms of complexity, it really wasn't that complex, and would be sort of on the lower end for price.

Conversely, a social photo app like Slide Photos that we built is a full social app. We did the logo, the branding, the back-end, the front end, everything. We also did a bunch of incremental updates to the app. We integrated Foursquare after the first version was released. It has a lot of features. That would be more on the higher end as far as price.

Are there any particular features or functionality that really drive the price up more than others? 

Yes. Just comparing those two apps, one of the differences is the application programming interfaces that need to be written to fetch new data from the server. Slide is a social app where people upload photos, and they can comment, follow, and like, and it has a login, and user profiles, and things like that. Everything is dynamic, so you always have to check the server to see if anything's changed and grab the latest. 

Anytime that you have an app that is dependent upon a server and user generated content, which are typically social apps or apps that have social features, they're more complex and take more time to develop, as opposed the first app that I just mentioned where there was none of that. It was really just videos that you could locally store on the iPad. You make an in-app purchase to download a video. Once it's downloaded, it's stored to your device, and that's really it. There's no other server side. So, anytime you have a server and API involved, it definitely makes it more complex and costly. 

In terms of your business model, are all of your staff locally and centrally based?

I only have a couple of employees who are local here. The other developers are remote, but they are all in the U.S. They're developers and designers that I've been working with for the last couple of years, but they work remotely from home. Offshore is more problematic. In theory, it sounds good, but it's definitely more problematic. 

What are the advantages to a U.S.-based service provider?

In my opinion, it is the expertise and communication. I pay my guys more than somebody overseas would pay, so you don't have the economics of an offshore developer for $20 an hour. You also don't have any communication issues. You have somebody who's in your same time zone and who you've been working with for a long time.

One way I could see offshore potentially working is if you have someone that is on your team that may speak the language, and maybe goes over to India, and the company owns the offshore development house. They regularly visit there, and they may not have those communication issues, and there are U.S. people there. So, I could see where there could be ways where it could work, but in my experience it's more trouble than it's worth. So, we have everybody here. 

How does your company estimate project price? 

Most of our projects, where somebody comes to us with an idea, a request for proposal, or a set of requirements, are flat rate. In our proposal, we do line items with all the estimated costs and give the client an idea of this much for development, this much for testing, this much for project management, and this much for a requirements definition if we need to do that. So, they're all line itemized at a high level in terms of the hours, which is how we get to our flat rate. More often than not, people want a flat rate, which we're able to give them. 

In other situations where somebody says, "We went offshore. It was the cheapest price. We just wasted a year of time. Now we've got this app that doesn't function. I'm way behind on my timeline. Can you review our source code and fix these bugs for us?" It doesn't necessarily need to be an offshore company, but nine times out of 10, it ends up being an offshore company that got them into that mess. In those cases, it's just straight hourly because we're inheriting someone else's mess, and it's difficult to fix things. In that case, sometimes you fix one thing, and it breaks another thing that was working. The architect that did it from the beginning was either junior or inexperienced, and was just kind of hacking through it. So, in those cases, it's typically hourly engagements. 

Does Blue Whale Apps take projects of all sizes or do you have a minimum budget? 

I wouldn't pigeon-hole it into "we have a minimum" because we've done a $10,000 project before that was really simple, maybe just a proof of concept type of thing with two or three screens. More often than not, for the bigger projects, it's not that we have a minimum number, it's just that the bigger projects cost more and take more time to do right, based on our experience.

About the Author

Natalie Craigmile Marketing Manager

See full profile