When it comes to mobile apps and projects, customer expectations have always been and always will be high. I believe this is even more so than a standard web application, because of the fact that the proliferation of mobile apps is intertwined in everything we do today, AND in everywhere we go. At the store, we check our shopping lists, during movies we text and read reviews, and when looking for something or someone, we use our mobile devices. So, as life moves highly fast, so too do our expectations of mobile apps.
We explored customer expectations in our last blog – namely around TIME. Time to deliver an app. Time to design an app. Time to use an app. But while that is a factor of importance for customers, so to is the cost factor. When implementing MEAPs, there seems to be a riff in customer expectations. Many customers out there do not necessarily equate an ERP project of considerable time and cost to what constitutes that which is needed to build a mobile app. And in many ways they are right. Also notwithstanding the fact of how they just downloaded a free app from the appstore this morning, and add in the fact that free is always good, and you can start to see the conundrum.
But mobile costs are so widely varied across quotes and estimates for projects, its really easy to confuse customers and prospects.
What we have learned in delivering mobile apps is that time is of the essence when it comes to cost. Plans to implement should be agile, lightweight, responsive – all the same juicy axioms that constitute great apps themselves. Planning for implementing an app also comes into play. Designing and creating for different types of apps also factor in. For instance, you may come up with 3 different price points for the same set of requirements, if you were to build an app natively, using mobile web, or using an MEAP like SMP.
With Native, costs can be lower if you have one off apps needed for simple straight forward apps that don’t require heavy logic writing or intense UIs or design cycles. If those projects do, than most likely time will need to be spent writing the Objetive C or Java to handle each and every one of those scenarios. Which is fine if that’s what the direction is. But, as an option for enterprises, this is why SMP is so attractive to customers, – many of these “connectors” already exist, thus the code overhead is minimized, and there is less reliance on sheer developer power. Sure, it’s still necessary to get the polished app you want, but you start the race further down the line. With SMP, especially the upcoming 3.0, native development is much more supported than in the past, and you still get the added benefit of the generated code for each major platform, and the existence of the already coded connectors. With these options, funds can go to improving the UI and gaining adoption, rather than sheer back end logic development.
Then there’s mobile web. Call it jQuery. Call it UI5. Call it PhoneGap/Sencha/Cordova – or even the Hybrid Web Container. These projects typically are lower in cost given that the libraries needed to create great mobile web apps mostly exists, and it becomes a project all about achieving smooth app screenflows, and whether or not you need to control the device apis themselves, or how much ram you need resident and available on the device to process graphics and such. But one of the things we pride ourselves on is building a native app, an SMP app, and a jQuery app, lining them all up side by side, and then minimizing the differences. When you can achieve that, you’ve created a great avenue for adoption and will have the basis to provide accurate cost options for any mobile project, and at the same time giving key options.
So costs are a product of many factors – and these options are chief among them. Consider also existing resources, skills, time, and complexity, then yank down the “options” lever discussed, and you should be able to give a really good idea of not only how much “time” it will take to build today’s polished mobile apps that customers expect, but also how much they will cost.
This is the second of a 3 part blog series where I dive deep into the drivers behind Customer’s Mobile Expectations. Today we focused on mobile costs. Next up? User Experience. Stay tuned, and happy reading.