Please introduce your company and give a brief about your role within the company.
Fingent is a Global IT company that crafts effective and efficient technology solutions which enable business success. Since our inception in 2003, we have developed custom solutions that have become central components in our client’s business success. Our technology and industry expertise enable us to partner with clients to deliver sophisticated solutions rapidly and on budget. Our technology practices include Mobile application development, Data Analytics, Microsoft platform solutions, Open source solutions, Technology infrastructure, Cloud Computing and SAP.
I work directly with Sam (Fingent's CEO) together with my colleagues in the Senior Executive team to provide technology and operational leadership.
Mention the objectives or the parameters critical in determining the time frame of developing a mobile app.
I believe that the following factors play a critical role in determining the time frame:
- The expected Business outcomes and business constraints
- Complexity of User Scenarios, including- features, potential user devices, demographics and tech affinity of the users.
- Compliance requirements- both Regulatory/Legal and Internal
- Technology constraints and requirements, including 3rd party integrations
There may be more, but these are the ones that come to mind now.
How much effort in terms of time goes into developing the front end and back end of a mobile application?
These days, anyone can use a DIY app maker to develop a simple app in 1-2 weeks. You do not need a team of developers to do this. At the other of the spectrum, we have worked on complex B2C apps, which have done outstandingly well in the app store, for over 3 years. The backend(s) and front-end of such apps continue to evolve to date.
These days we are able to create MVPs (Minimum Viable Products) for sophisticated applications in 2-4 months, working on the backend and front end in parallel. MVPs tend to need a greater focus on the front end. As the app moves beyond the MVP stage, the backend takes up a greater proportion of the effort.
Then again, a good app keeps users happy by evolving to meet changing/increasing needs. It adapts to business changes and upgrades to newer technologies in a cost-efficient manner. Good apps, which lead to successful business outcomes, constantly evolve. They are both complete and incomplete at the same time!
What is your company’s business model–in house team or third party vendors / outsourcing?
At Fingent's development centres, we have excellent in-house teams and do not outsource to third party vendors. This approach is a result of our focus on creating the right balance with People, Processes and Product, which we believe will help us grow together with our clients.
For example, we work with a balanced matrix organization structure- so while the Project focuses on securing coherent delivery with a razor sharp focus on our customer's business objectives, the Line focuses on the sustained development of specialized competencies required to create top notch apps.
We only work on projects where we believe that we can add significant value towards helping our clients achieve desired outcomes. Such outcomes may include - creating new revenue channels, improving process efficiency, improving customer engagement, societal change, improved brand visibility, better decision making and more.
We are very transparent with our clients, and provide them with good visibility throughout the software development process.
How is your business model beneficial from a value addition perspective to the clients compared to other companies' models?
Before we start development, our account manager and analyst try to understand the business or societal outcomes that our client aims to achieve. They then validate the function of the proposed software towards achieving these outcomes. A good understanding of the expected business outcomes secures that we build the right software application. We deliver usable prototypes as early as possible, so clients can install these on their devices and get a feel of the real app. Involving clients throughout the development process, helps in early validations and course corrections which are important to keep projects on track.
The focus on competency development ensures that we are able to choose the right technology for the job, instead of shoehorning our clients into solutions that may not be fit for purpose. Our organizational structure allows us to bring in people with the right competencies for the job, across the product and service lifecycle. We can pull together good multifunctional teams with competence across all areas which are critical to building a good solution - user experience, programming, software testing, system administration and project coordination.
Having the project team on the same location enables good communication, ideation and continuous process improvement.
What are the key parameters to be considered before selecting the right platform for a mobile application?
In addition to business requirements and target audience, such a choice is also influenced by the feature set, feature scalability, the user interface needs, the need to work across multiple platforms, third party integrations and the kind of enterprise integration required. These determine the technical approaches - Say, do we use platform-specific SDKs for iOS (iPhone and iPad) or for Android or instead go cross-platform with HTML5 and tools like Phonegap, Flex or Xamarin? Do we do the backend in .NET or would an open source tech like Php or Python work? We try to identify this as early as possible in the process.
Which platform do you suggest your clients to begin with when they approach you with an idea (Android or iOS) and why?
We do not shoehorn our clients to start on a specific platform, but instead work together with them to identify the optimal launch pad. There is no one size fits all solution. We recently deployed a B2C app targeting an upmarket American audience on App Store. iOS was a better platform to begin with so the client could realise a better ROI on the MVP for two key reasons. This worked due to two key reasons: A good percentage of the target demographic used iOS, and fewer form factors and target OS versions lowered development costs; that the app was amongst the top 10 on the App Store, validated the decision and led to the subsequent development of the app for Android too.
On the other hand, Android was the better launch pad for an enterprise field services app for contractors. The low cost of Android devices facilitated the early deployment of the solution across a large number of contractors, which helped our client realise process efficiencies at a lower cost. We are now building an iOS version of this app.
Sometimes the right platform to start is neither Android nor iOS. Last month, we successfully deployed a B2B app for one of our clients, on Windows! It made sense to begin with Windows since they were able to deploy the app for a large enterprise that provided all their employees with Windows phones. This helped them validate the business case, using an MVP, with a captive audience. We are now building iOS and Android versions of this app.
What are the key factors that you consider before deciding the cost of a mobile application?
The features of the app, the complexity of the user scenarios, the target platforms - all these and more, determine the activities required to build an app and hence the cost. Whenever possible, we do a thorough drill down to create project estimates across design, programming, testing and deployment activities. Furthermore, we seek opportunities to reduce costs by using our reusable frameworks, open source options and microservices, wherever feasible. Overall, this helps us estimate the personnel requirements, the calendar duration ... And hence the estimated cost.
What kind of payment structure do you follow to bill your clients?
When the project scope is well defined and the risk of changes is very low, the Fixed Price model works very well and this is what we recommend. We require a small upfront fee and then invoice against milestone deliveries, with the final payment due when the application goes live. Post deployment, we usually move into a retainer model for feature augmentation and maintenance.
On the other hand, when the scope is fluid, and the risk of mid-course corrections is high, we recommend a Time and Materials based approach, with monthly billing based on the resources allocated to the project.
We have also executed hybrid models, combining FPP and T&M for some of our clients.
At Fingent, we do not have a preference for one model over the other, but usually try to work out a plan that best suits the engagement. We offer a warranty period for our apps.
Do you take in projects which meet your basic budget requirement? If yes, what is the minimum requirement? If no, on what minimum budget you have worked for?
Yes, we take in projects which meet our minimum budget requirements, which is USD25,000. However, we sometimes waive this for - clients who have been with us for a long time, for references from clients, for projects with large social impact and for interesting projects which help us explore bleeding edge technology opportunities.
What was the cost bracket of mobile app projects your organization did in 2015?
USD 5000 to USD 150,000
Which business model do you suggest to generate revenue from mobile applications? Why?
There is no single model that would work for all our clients. In the B2C world, some have used mobile applications as a new revenue channel, piggybacking on existing online or offline product or service. Others monetize directly via traditional methods like pay per download, freemium, in-app purchases, transaction charges and ads.
For most of Fingent's Enterprise clients, the mobile application has usually been an integral part of a larger modernization program. One of our clients, the CTO of a property maintenance firm, estimated that they were able to cut operational costs by over 70% through process efficiencies enabled by the solutions we developed for them.
