Interview with Stanfy

Please introduce your company and your role there.

I'm Andrew Garkavyi, the CEO at Stanfy, a mobile and wearable software development company. We help our customers to bring their ideas through the different stages of discovery, design, engineering, and quality assurance until the working product is actually ready to go to the market, so that's the variety of expertise we have internally and what we do. I'm personally in charge of everything that's happening inside the company.

What are some of the objectives or parameters that a client needs to define in the beginning before building an application?

Generally, if the client comes to us asking advice or for a quote, they may have nothing but their idea and that's it. They come to us and we can discuss the idea together, and then work out or list out some features of the app. We would definitely look at the competitors on the market and what our customer will be putting in their app, what they are trying to achieve with this project, who will be users and how they will use the product. By knowing that, we can move further through the other stages.

What should a client consider before choosing to go with iOS, Android, or another platform?

Each project owner should consider his or her target audience. The iOS and Android markets vary a lot. The Android market has a large device base. They have lots of users and lots of devices. If your product is targeted towards the masses, for example, some kind of family service, or maybe just the expansion of some enterprise software or service that already has a large user base, which may be a good choice for Android. For example, if you have your service hosted on a website already and you see that there is a large amount of people in your market with Android devices, then there's definitely a good reason to go for Android and maybe consider iOS as the second choice.

But, if you're a startup and you have an innovative idea and you're not sure about how your idea will work out, then iOS would probably be preferred choice. In terms of earning revenue, iOS is still known as a much better market, and if you're looking for more of an early adopter audience, iOS is the way to go. It really depends on your target audience. You should know your users or at least think in advance about who you want to reach.

What about hybrid or cross-platform solutions? Can you define what those are and in what instances they are used?

In my perception and probably in the mobile world, hybrid is more like a native-based app with the inclusion of Web elements like HTML5 and CSS. There is another option called a cross-platform solution, which is purely HTML5, or may be compiled from JavaScript or other codes to native binary. So, there is a difference between the truly cross-platform solutions and hybrid solutions. Hybrid is basically a native app with some kind of universal content that is used inside. A cross-platform solution is basically an app that will look and work the same way on all the different platforms. 

There is a perception in the enterprise world that the cross-platform solution is the way to go because you can deliver faster in the market and, in some cases, this is true. I would say it is true if you care less about the user interface and user experience. If you really care about how your app looks and functions and how your app is perceived by users, at this point in time, you wouldn't probably go cross-platform, because whether you're using HTML5 or tools like Appcelerator, there are still performance problems. These options are limited in the different UI compatibilities and how you can style different elements, so there are still many problems that they need to address. If you really care about performance, responsiveness, and the UI of your app, you should consider a native solution. So, no matter whether you're enterprise or you're a startup, everything depends on your aims and goals.

Does Stanfy do hybrid implementations?

Yes, but rarely and we are not using cross-platform tools. In terms of hybrid, as defined previously, you really need to know why you are doing hybrid and you need to understand that you'll benefit from that and not have problems. I would say that hybrid solutions seem to work very well if you have a content-heavy application that depends 80 percent to 90 percent on the content you're displaying. Your content may vary on the types of formatting, styles, etc., in which case it may be much easier to go with a hybrid, because using HTML, CSS, or some other tools to simplify the process of visualizing the information is easier. Instead, if you go with a native solution, it may be time consuming to apply existing tools in order to style and format information.

What some of the key drivers of the cost to build a mobile app?

That's probably the first question everybody asks, which is totally understandable. I often compare it to the cost of building a car or a house. If you look, for example, at a BMW, there is a series 1, 3, 5, and 7. They are all still cars, so they do their function and they deliver you from point A to point B, but the cost of those cars is way, way different. You pay for Series 7 sometimes five times more than Series 1. To some degree, that's similar to apps.

A lot of times, depending on how careful you are to the details of the app during the planning process, even if you take one screen of the app, different companies' engineers will give you absolutely different estimates. One would tell you that screen would take two to four hours to build and another would tell you 16 to 20 hours, and they're both right. The second one, because of his experience, knows the amount of problems that he may face and he will need to address, whereas the first one thinks more in terms of just delivering the core functionality and leaving all the corner cases out of it, and those are the things that really reflect the overall cost and complexity to build a product. That's one of the very basic things that differs a lot. We had a customer who came to us and asked for quote. Sometime later, he returned to us and asked, "Guys, can you explain? I got five quotes and those quotes range from $20,000 to $200,000." This is a real actual case. We tried to explain to him all the different things that can be inside, and as a result that company decided to hold off and do a bit more planning and discovery in terms of whether they were actually ready to build a product. That's the reality of the software that we're building. 

Of course, a lot also depends on the functionality and complexity of the app. You may be building visually a very small app, but it may have lots of things underneath, so all of that influences the cost since it's based on the time that you spend to build that app. Everything should be taken into account. In our experience, for projects that are longer than something like two months for a team of two engineers, it may be hard to give an accurate cost estimate in short time because there are too many different factors that you need estimate and to take into account, unless you are ready to spend time and money trying to write specifications that most likely will change.

How do software development companies approach cost estimation for projects?

The first intention of any client is to reduce cost, so they want to understand what the cost is before actually beginning a project, which is totally understandable and fine. But, in order to give that understanding, you need to think about all the different issues and possibilities, which is pretty hard, and for larger projects, it may take weeks and months to estimate. That approach is like a hardware engineering project or construction project, where they spend years actually designing structures or a building before actually building it. So, that's one approach, which can be very expensive.

In the software world, quite often what you can do instead is you can actually start from something small and then see how markets react to that product and then evolve it. You can change your product very rapidly and you don't need to plan years before all the functionality. That's actually another type of mistake lots of companies do and have done in the past, where they try to put lots of things inside a product, and then probably 80 percent of those functions that they put inside are never used.

Do you normally prefer an hourly rate or fixed cost project?

Of course, from the developer's perspective, we prefer to use the hourly rate model because it reduces lots of problems for us, but we need to think from the business perspective because that's what the real aim of building software is. We need to address and solve problems that the client's business has. The reality of the business is that they need to control costs. If you have a relatively small project, then you might be able to estimate the price up to a limit rather fast. In most cases, there will be some range so it's pretty hard to fix the price, but at least you can have some understandable range. But, if you're going for a product that will take you months or years to build, it's probably impossible to go for a fixed price unless you reserve double or triple the price from the initial quote because during the development, there will be plenty of cases that you hadn't ever thought about initially or as soon as you see how it works in reality, you may decide to actually change it and go the other way.

What are the advantages to working with your firm in terms of its business model? How does it compare versus a local firm, a freelance team, or other models?

In terms of the advantages of working with us, we're really focused on delivering the product as a whole, not just separate bits and pieces, so our goal is not to do only coding or only design, our goal is to actually deliver a working product and this, we feel, is very important for a business and is one of the advantages. We are able to address all the different problems and issues that arise throughout the process in order to make the product work, regardless of what those issues are, whether it's UI/UX issues or engineering issues, all of that can be solved. We feel that's a rather important thing. 

In terms of selecting local partners versus offshore, nowadays I think that's not the most important question. Of course, it's much better to have a person next to you sitting in the same room because it reduces a lot of the problems and communication obstacles. Today, when we have high-speed internet and all the tools like Google Hangout and Skype, I think it's not a problem, and from my perspective, it doesn't really matter much whether you work with a local company or with an offshore company.

If you're trying to think about whether it's better for you to go with a freelance team or with a company, you really need to think about what you're trying to achieve and what you're looking for. If you want to be guided through the process, and if you want a development partner who has a sustainable process that they have done many times before and that knows how to do it for sure, then you would probably prefer to go with an existing company and work with them using the process that they have. If that aspect doesn't matter or you're not afraid of this and you're really prepared for a bit more challenging process, then you can go for freelance type of work and try to gather a freelance team together. It really depends on your aims and your reality in terms of the time you have and budget constraints. Sometimes, freelance will cost you less because you're not paying extra for some company costs, but it may cost you additional time, which obviously may convert into more money and quality problems.

About the Author

Natalie Craigmile Marketing Manager

See full profile