• My Tools
App Development,

Interview with MentorMate

January 30, 2015

by Natalie Craigmile

Marketing Manager

MentorMate logo

Clutch spoke with Stephen Fluin, Chief Strategy and Innovation Officer at MentorMate, as part of a series of interviews on mobile app cost and platform choice.

Learn more about MentorMate on their Clutch profile or at mentormate.com.

Please begin by introducing MentorMate and your role there.

My name is Stephen Fluin, and I'm the chief strategy and innovation officer at MentorMate. We imagine, design, and deliver mobile and Web applications for companies. We work with both established firms as well as startups and those people who have never built an app before. We work with our clients from end to end to help define what an application should do, how to price it, how to market it, how to build it, and how to launch it. Then, we do everything involved with that, from the marketing side, the development side, as well as consulting and strategy. Our CEO, Bjorn Stansvik, was developing software for Palm Pilots in 2001, years before the iPhone, so we've been in the mobile space for a long time.

Mobile App Platforms

What are the items a client should define before they select what type of platform to use for their mobile app?

The number one issue, from our perspective, is going to be the users and demographics that you're targeting. Moreover, there's this thing that I call the tyranny of the user, which is that their expectations continue to shift and their devices continue to shift. You have to continue to follow and engage them along their journey. For us, some of the first questions we ask when onboarding a client are, "Who are your customers?" "Who do you want your customers to be?" Then, depending on the demographic, the income bracket, the industry, and whether it'll be used personally or professionally, we're going to see different device needs.

For example, in the engineering industry, we see almost exclusively Android. Whereas in the medical space, we see almost exclusively iOS. We tend to see higher income individuals preferring iOS. We tend to see lower income individuals preferring Android. But, it's also the number of people you're trying to hit. So, if you're trying to hit 60 percent or 70 percent market share in terms of mobile users, at that point you probably need both iOS and Android. It's always going to come down to what the users are holding in their hands.

Going from there, when it comes to the question of Web versus native, and how to build that piece, that's going to depend more on the experience. We find that the best experiences are built with native applications. With a hybrid strategy, there is a tradeoff between user experience for a lower cost. We help our clients understand the tradeoffs and the realities in terms of cost and time to develop and maintain a strategy long term.

Can you describe an example from your experience in which that hybrid option was optimal?

One example was a partner that had already built an extensive Web portal for management of hardware devices. We looked at rebuilding that natively which, in the long term, was definitely a desire. But, in order to get to market quickly, we wanted to be able to reuse and leverage the existing JavaScript code, where they had built a lot of business logic in a few years. In this case, it was better to stay hybrid, and we just built a wrapper that would enable it to run on iOS and Android.

Do you also build mobile Web apps?

It depends on what you mean by mobile Web apps. We build many desktop Web applications, which are applications targeted at laptops and standard desktop computers, and sometimes tablets as well. We also build a lot of responsive Web applications, which are applications designed to render well on a variety of form factors using only Web technologies. Companies used to build "m dot" sites or mobile-only Web applications, but these have begun to be punished by Google and other search engines, and they can get in the way of user experience, so we try to avoid them.

Are there any examples from your experience in which Android first or Android only was the best option for the client?

One of the companies that we worked with does on demand contracting. A natural disaster or emergency will happen, and they'll send out 10,000 notifications instantly, and then collect individuals that are willing to contribute, support, and help. These are about 98 percent Android users. So, in that use case and for their demographic, there was no need for an iOS application.

Do you also build Windows Phone apps?

We do, but we used to do more of them when the platform was new. The demand has almost completely dried up from our perspective. We used to consider Blackberry, Windows, iOS, and Android, but now it's almost exclusively iOS and Android. That's not really us pushing, it's just that there are not a lot of users out there.

Regarding iOS and Android, does one platform cost more or take longer to develop than the other?

In general, we treat them about the same. When it comes to developing for iOS versus Android, the net total, end of the day cost is going to be about the same. What we say internally is that the differences between one developer to the next are going to be greater than the differences between iOS and Android. Developers tend not to be fungible and all equivalent. Some are faster than others. A fast Android developer is going to do an Android app faster than a weak iOS developer and vice versa. A fast iOS developer is going to do an iOS app faster than a weak Android developer. 

One challenge we run into is on iOS side of things is that development takes a little bit longer for certain use cases. In general, the iOS tools are fantastic but, in terms of distribution, there are definitely more headaches there. Some of the initial set-up pieces can take a little longer as well. But, what happens is that Android ends up taking longer due to the number of devices and screens that you're targeting. If you're only targeting a single Android device, Android might be a little bit cheaper, but that advantage quickly goes away when you consider the multitude of devices out there.

Mobile App Cost

What are the key drivers of cost for building a mobile app?

The number one driver would be the functionality you're putting into it. How many screens do you have? How many states do those screens have? What are the algorithms and calculations are going into those screens? 

Number two would be any sort of third-party integration. Every time you add a Facebook login, LinkedIn login, Google Plus integration, game integration or some sort of back-end, those always add a huge amount of complexity, especially if the backend wasn't built with mobile in mind.

Does MentorMate have a minimum budget with which you work?

There are many notable exceptions but, in general, we don't do projects smaller than $20,000.

What might those exceptions be?

For us, if it's maybe the first in a series of applications. Maybe we need to get the initial application out the door for cheap, and then there's going to be a follow-up application, things like that.

How do you go about figuring a price quote?

We first start with what we call business needs first from a user's perspective. What are we trying to accomplish as a business? Then, we go into the user perspective, so we do an inventory of who the users are and where they're coming from. We use that to decide the right approach for them, whether it's hybrid, native, or responsive Web. Then, we go deep into the set of functionality for the application, and then figure out roughly how much time we think this will take. Then, we apply a standard buffer and add in the auxiliary pieces that are necessary for application development. We start with the development and coding side of things, and then we work backwards and figure out what the project management, quality assurance, design, system administration, and all of those pieces would end up being.

We don't do fixed price, but we do give an estimate cost per feature, with the understanding that often clients will change features or drop features. So, we try to give them as much flexibility and control as possible.

Can you describe a little about your business model from a cost and value perspective? How does it differ from hiring a purely local firm or freelance team?

First thing I'll say is that we're really trying to be an end-to-end partner for our clients. Most of our customers don't come to us with a spec. They come with an idea or a problem to solve. We're really confident and able to help them figure out what they should be doing. It used to be, ten years ago, that the business would just decide, "We want the technology to do this," and then the technology would try to deliver that as cheaply as possible. But in the modern era, we see both the business informing the technology choices as well as the technology informing the business choices for most of our clients. 

So, really, I would say we do a better job than a lot of firms building the right thing, by being more consultative and being a partner with all of our clients, especially when compared to freelancers. Freelancers tend to do just what you tell them. Compared to United States-only firms, I would say there's definitely a cost differential. We have U.S. developers, we have U.S. team members, but then we also have an office in Europe. We tend to blend those strategically to figure out what things can be done more cheaply, and what things need to be done in person.

We also draw a distinction between ourselves and most companies that have a global presence. We especially contrast ourselves with China-based or India-based firms because all of our team members speak English and they're expected to interact with clients directly. We look to hire people that are willing to challenge ideas, and willing to take ownership of the ideas, which is a more Western mentality than a lot of firms.

Related Articles More

7 Questions You Should Ask Before Building Desktop Applications
When to Hire a Freelance App Developer vs. App Development Agency