iProgrammer Solutions Private Limited

It depends on application to application basis. There is no thumb rule as to if the same amount of time or similar kind of a matrix will work in the backend and the frontend for a different mobile application. Different applications may have different requirements from backend and frontend development. For example, if we are developing a simple gaming application, then, in that case, the work required in the front end is more than is required at the back end. If it is a business application, basically fetching and showing data using web services, then the efforts required on the back-end may be more than the front end. Unlike web development, the market of mobile applications and the scope of mobile applications are very open ended. Within the mobile space, a lot of innovative usages of the devices and API’s keep on happening which prevents restricting or binding the mobile application to a very specific kind of a framework or a pattern.

We have a completely in-house team which looks after the server side applications, the management part, mobile application development - front-end part and back-end part and all the related activities, so it’s a completely in-house team. We have a team of over 100 people who look after all the different aspects of a mobile and web application.

Primarily, there are two or three factors that we consider which our USP are: Firstly, at iProgrammer, we believe in staying ahead of the technological curve. The drive to keep on exploring the newer aspects of technology in this domain keeps our team at the forefront. By implementing these technologies into applications wherein the client may not even be aware, our responsiveness and understanding of the new technology keep on adding value to businesses.

Secondly, one of the main advantages a start-up or an entrepreneur has is that our team members have a business oriented mindset with an extremely geeky involvement in technology. Interacting with the businesses, listening to their ideas and helping them evolve into better products are our ideology. At iProgrammer, we like to interact with all our clients to an extremely deep level and to understand their core project, the central idea, the usage matrix and give them technical as well as business related inputs which we believe could be of use to them. Many times surprisingly we have been able to really add value to the clients’ offering using these interactions and our involvement has ended up building a product which is better than what was initially visualised. It has also benefitted the entrepreneur and most of our clients like that a lot. Whenever a new client is coming on board or even is just evaluating us, one of the primary things that he demands is that if he tying up with iProgrammer for his development needs, he would be interested in getting consultation and brainstorming sessions so that together we can build a superior product. We offer a solution and a product development centric mindset.

The first thing to consider here is the audience of the product. Starting with the kind of audience the client is seeking, we go into demographic research to identify the kind of user matrix it has; between iOS or Android (or Windows - if that has to be evaluated). We generally do not advice any of the start-ups to go ahead with Windows, if the product is focussed for the Indian or the US market. Windows does have a decent hold in Europe but definitely not in the North American or the Asian (Indian) hemisphere. So this leaves us with two decent options: Android and iOS.

Especially in India, Android has a much larger user base, so if your product is something which has a much wider audience base and may involve a lot of youngsters and middle income or lower middle-income audience, then Android is the platform that we recommend to go ahead with because that is where majority of the audience is given the market share ratios between iOS and Android. However if the client also has a product that targets niche upper middle class, it may have iOS, then we look into whether there is a need for iOS development or not.

Technically many of the start-ups will also go by the idea where we suggest only going with the Android if that connects with their audience and then once the Android application is there, we start collecting a lot of analytics and inputs, requests on the website as to what kind of traffic is coming from which sources. Accordingly, if we see that there is a decent chunk of users coming from an iOS platform then yes we move ahead with that development.

However if it’s a US based client then things may change, there the user base for Android and iOS is almost equal, given the subsidised device model that they have. So then it goes a lot more into demographics, analytics, the target audience, understanding the core value to decide which platform to move into. In India it is lot easier but in the US, it is not straightforward to choose one platform over the other. In fact, most of our US clients end up developing both iOS and Android application right from the onset as compared to the Indian markets where Android is the need of the hour.

There are two primary aspects to pricing: first being the type of platform we would be developing and secondly, the effort that would be needed in developing the application. The first initial draft of the application comes at a fixed cost and then, later on, we can keep on adding value addition to the product, like coming up with newer features.

For example, once the application is live, now over the period of the next one month we collect a lot of analytical data from the users: behavioural patterns of the user, most used features, least used features, features that are most interesting and how can we bring them to the forefront to make it more user friendly, which features can be done away which people are not using. When you start as an idea in a start-up, you may not necessarily have a complete understanding of your user’s behaviour. So the product which might go out still needs some kind of a validation, so the first month gives us that kind of an understanding. Based on these figures, other engagement starts where we keep on adding and enhancing the product on an on-going basis or on a need basis. This again goes into a different model where any change request or any enhancement that needs to be done is evaluated in terms of efforts and on a time & material basis, the quote is provided.

We are always open to the user’s discretion when it comes to payment. The general structure is asking for 15-20% of the total cost as upfront and then milestones are set for the product delivery, designs, initial first draft of the application, back end, front end, and the authentication layer and so on. Each of the sprints has a milestone defined to it and against each milestone, a portion of the payment is collected with the final payment being set at a time when the application is already live and all the bugs and crashes which are reported have been taken care of.

We do not have a minimum price point, we have an interesting point. If we get a project which we find interesting, even if it is a very small project, we would like to involve in it because it may give us insights into a new technology and gets us to help somebody who is starting out. We are open to building anything as long as it interests us.

There is a lot of variation in the way mobile applications can be monetized. It all boils down to the core need that the application is serving. If it is just an exploration application or a discovery application, like a content based where the app is fetching articles from different websites and showcasing it to the reader on a single screen, in such cases, advertising may be the right approach. However, within that also you have a very different audience base; let’s say you are only going to target on good quality economy or finance-related content and your audience is stockbrokers, financiers, investment bankers who would be willing to pay a slight amount to get access to that kind of an information with a single onset rather than going to numerous different applications or platforms to read that content, then a subscription model may come handy. Today, a lot of blogs have started offering a paid subscription.

There can be advertising which is another way of monetizing which typically happens with games. But if there is a core product that you are offering as a feature than advertising may not be the way, then you have to identify one time paid cost or something similar that works best.

Many times the application is a support function to the core business which is not meant to make money, it is just to support the existing user base and enhance their experience. In such scenarios, any kind of a revenue generation from the mobile application should not be looked into as the primary goal of that particular mobile application.