Clutch spoke with Paul Fruia, VP Engineering at Softeq, as part of a series of interviews on mobile app cost and platform choice.
Please begin by briefly introducing your company and your role there.
Softeq Development is a software consulting company, and we specialize in custom software. We have experience in everything from low-level embedded firmware to desktop to mobile to Web applications. I am Paul Fruia, and my role is vice president of engineering. I'm mainly responsible for relationships with some of our larger clients and performing project management duties as needed.
Does Softeq develop enterprise apps, consumer apps, or both?
We do both. We've actually done more enterprise app development than consumer app development, just because of the business relationships we have with some larger companies. NVIDIA is one of our largest customers, and we've done a lot of internal applications for them, things that aren't available to the general consumer. I'd say a large portion of our business is in enterprise application development; however, we have done quite a few games that are consumer oriented, and even won the Atari Pong challenge a couple years back with more than 90 entrants in that contest.
Mobile App Platforms
What are the objectives or parameters that the client needs to define before they decide on a mobile app platform?
The main thing is meeting their customers' needs. So, we need to determine the right platform for their target audience and for their application. I think that's critical because you don't want to have a very busy form-based application running on a very small screen, like an iPhone or something like that. That really should be running on an iPad or a larger screen. That's the first thing to look at.
Another key driver is, has the customer standardized on a particular device? We see that a lot. Various companies will call us and say, "We've adopted the Samsung Galaxy company-wide, so that's the device we need you to design an app for." At that point, it takes the guesswork out of it since they've already made a decision. Depending on the client, we'll see various platform selections. If we have an opportunity to help the client in that decision, we will. It's really based on the complexity of the content more than anything. Some other key factors that might come into play would be network connectivity and security.
Does Softeq also develop hybrid apps?
Yes. We have done that as the need arises or as the application permits. In our experience, a hybrid app really only works as a wrapper for a Web container, or maybe a PDF viewer or something like that. It works where the content is common to both platforms. Where you run into difficulties is when you have functionality that requires access to native features of the device, for example, the calendar or contacts, things of that nature, or hardware specific features of the device like a GPS or accelerometer. Once you start getting into those aspects, like if you're doing a game or something like that that's not strictly an HTML5-based game, then you would be getting into hardware mechanics and hardware support that need to be provided, and that's going to necessitate a native app. There's just no way to support it using hybrid tools.
Are there any examples that come to mind for which a hybrid app was ideal?
There was one we built that's a magazine rack app. In this particular case, it was just a presentation of content. It was content that was commonly supported on any platform. It wasn't an app that required native support on the device, so it was a natural fit for hybrid development.
Are there any specific use cases for Windows apps, in your experience?
Again, primarily it's been our enterprise customers that would come to us and say, "We've got users that are on Android, users that are on Apple devices, users that are on Windows devices. We need this app to function across all platforms." We would develop comparable native apps for each platform. One application that comes to mind would be a product called NVContacts, which is basically NVIDIA's internal company Rolodex that we developed for them, and that runs on all three platforms.
Is that app an example for which you really needed that native device functionality as opposed to a hybrid app?
Right, because it uses contact information, and calendar, and things like that. It uses the specifics native to the device, and it didn't make sense to utilize a hybrid approach there. Also, that particular application requires a high level of security, and the implementation of that security is different depending upon which device you use.
Generally, is it best to start with iOS first or Android first for a consumer app?
One thing that most people don't know probably because there's more marketing buzz around Apple is that there really are more Android devices in the market. So, if you're trying to reach a larger audience, then you want to design for Android and not Apple first. However, you're probably not going to make as much money on Android as you would on Apple.
Also, in our experience, we've found that it's usually a little easier and faster to develop for Android, especially going through the application approval process. With Apple, that process can be quite painful. It's one of the unknowns of doing iOS apps. You don't know how long it's going to take to get through that approval phase with Apple. Apple has to review it, and approve your entry of that app into the App Store. Best-case scenario, Apple responds in a week. Worst-case scenario: three to four weeks. If Apple, for whatever reason, declines to accept your app, then you've got to make the changes that they require, resubmit it, and again you don't know how long approval will take. Sometimes, they'll fast track it once it's been through once, and they know there are only one or two things they're looking for. It may have taken three weeks the first time; it may only take a week the second time. Still, now you're talking about four weeks as opposed to an Android app that, as soon as you're ready to publish it, it can be in the App Store the same day. So, depending on a customer's urgency, we may recommend going with Android first because we can probably get it to market quicker.
Does this processing time add additional cost to iOS app development?
Additional costs could be in opportunity costs with the app not being available. It could also be additional development time required because for whatever reason Apple, in their infinite wisdom, decided that your app didn't pass muster, and you needed to change something to meet their standards.
Some say that it can take longer to develop an Android app because of the device fragmentation and somewhat less sophisticated development tools. Have you found that to be the case?
No. We don't agree with that. I think that's marketing spin against Android. The fragmentation doesn't seem to be that much of a problem and the tools are pretty easy to install and run on pretty much any platform, whether it's Windows, Linux, or Mac OS. On any platform, the tool is supported, whereas you can only develop on a Mac operating system for iOS. So, you're really locked into their tool chain and really locked into the way Apple does things. I don't think we would agree that it's harder to develop on Android. If anything, it's easier.
Mobile App Cost
What are the key drivers of cost for developing a mobile app?
Depending on the complexity of the app, the research and discovery and scope definition could be a day to a week or two weeks. So, that can really impact cost. I would estimate that planning and design is between 10 percent and 15 percent of the total cost of the project, depending primarily on the complexity of the application. The platform selection has minimal impact on cost; however, as I mentioned before, our experience has been that Android development seems to go a little faster and easier.
The biggest cost driver is the features. The complexity of the app, how many buttons, how many fields, how many screens, the amount of logic required, that's 60 percent to 80 percent or more of the cost of the app. Infrastructure and app administration is typically 5 percent to 10 percent at most. Then, testing and deployment is going to be in the 5 percent to 15 percent range, primarily influenced by complexity again. You would spend more time testing a more complex app.
We don't typically include ongoing support as part of our initial project cost. We do provide maintenance and warranty offerings for our customers, but those are usually agreed to in a separate cost. If the customer wants one year of support, then depending on the level of support, to make updates to the app for any changes to OS versions and to fix any bugs found during the next year or so, and if they want these things done in short order like a one- or two-day turnaround, then we're probably going to charge about 15 percent of original project cost for a one-year warranty. It's negotiable, depending upon on the level of the warranty but, generally, it's around 15 percent.
For enterprise apps, why is access to enterprise data such an unknown in terms of cost impact?
At the beginning of a project, the customer can say, "We need you to integrate with our system, and this is what we have." It's generally pretty nebulous until we get into the project and start looking at what existing legacy systems we have to integrate with. Much of the time what happens is that we'll either have to wait for an internal resource from our client's side to develop something on their end, and go back and forth with them, testing and debugging the interfaces to make sure they're working properly, or we'll end up having to develop them ourselves because they're not capable. Sometimes, we know ahead of time what's involved, and we build that cost in.
It's happened in the past where the integration with customer data has been more difficult than anticipated, or at least initially conveyed to us. That said, we do it all the time. Almost any project that's of any substance, especially enterprise apps, they're going to have a back-end connectivity piece. That's just the challenge that we have to deal with, on almost on any of those kinds of projects where we have to connect to existing or legacy data.
How do you normally price projects and charge the client?
Most customers want a fixed price, so we do our best to estimate the project and provide a fixed price. As I mentioned, sometimes we don't know what we're up against as far as the internal company data resources and things like that. In those cases, we have to add a risk factor. So, if a company insists on a fixed price, we'll do it based on what we know, and for the things we don't know we'll add risk factors, and we'll come up with something we're comfortable with. That's what most companies want.
We do have customers that will hire our developers to augment their staff. They've already got one or two guys that are working on the project, and they need one or two heavy hitters to come in and help them wrap it up. In that case, we'll charge time and materials. We would hire someone out for an hourly rate.
Then, the final scenario in which we work is that we have some long-term projects where a company will hire a team. Based on the length of the term, and the number of people on the team, we'll negotiate a standard rate. They'll just be billed accordingly for the terms of that purchase order, essentially.
Do you have a minimum budget with which you are willing to work?
As far as our mobile projects go, we've found that the minimum entry point for a mobile app is around $15,000 to $20,000. That's not necessarily saying that we won't do something for less than that, but that's generally what you're going to have to spend to get something of quality. We do consider all projects, we have taken some projects that cost less than that but, typically, they're more. We take it on a project-by-project basis. We do have people that contact us with unrealistic expectations, and that's why we like the fact that you're doing this survey. It helps communicate more realistic expectations to people, to know what they can expect, know what they're getting, and know that people do make money selling games in the App Store, but it costs money to have those games developed.
In terms of your company's business model versus others, what is beneficial about how your company operates from a cost perspective?
The way that we are structured is that we have accounting, some marketing, some research and development, and some project management onshore here in the U.S. We do have a couple of people here that can do development but, by and large, the development resources here are much, much more expensive than offshore.
Six years ago, we decided to open our own offices in Belarus. The resource rates are very competitive there. They're not super low, but they're definitely much less than the U.S. We're able to find highly intelligent people there because they have a lot of universities. Minsk is like the Silicon Valley of the former Soviet Union. We're also constantly doing training, so we're helping our people to grow professionally. We have English training classes, so we foster improved communications. Since we've been there a while, we're able to get out of our teams what we want and expect. Whereas, sometimes, if you're dealing strictly with an offshore team, there can be issues with communication. We've bridged that gap by having our own facilities and our own people, and people from the U.S. that are there helping to run it and also helping to grow the staff to be more fluent in English and have better communication, and to help them understand.
So, that aspect, and that we offer U.S.-based project management if needed or desired, we think helps to make the projects more successful. We're not necessarily the cheapest in the business, but we feel that we're very successful because we're able to accomplish what the client needs, meet their pricing and time deadlines and, in general, it's worked. We judge our success on the third or fourth project with a customer, not the first. We have many return customers.