You need an app. Now what?

We’ve all felt the high of finding an amazing new app that makes our lives better or easier, as well as (perhaps more memorably) the frustration of inadequate technology robbing us of our valuable time.

A decade since the iPhone was first released, the App Store and Google Play are littered with apps of questionable quality and low user ratings that you’d never download; an inevitable waste of your valuable time (not to mention those who developed them!).

So to ensure your app is successful, it pays to involve your users from initial scoping through to final testing, via feedback forms, polls, surveys, and focus groups. 

Most digital projects have a deadline, and high stakeholder expectations for features - two factors at odds with each other - so carefully managing these reduces the risk of investing in yet another app that nobody loves.

Any good app will be clearly branded. In fact a key objective for many app projects is to positively influence perception of a brand, drive awareness of it, or both.

Failure to meet the needs of users will result in irreparable damage to your ratings in the App Store and Google Play. This creates a downward spiral of negative reviews, which discourages more downloads - the very thing needed to attain positive reviews of an improved version. 

In summary, the long term reputational risk of a failed app project often far outweighs the perceived reward of meeting the original deadline, so it’s vital that stakeholders really understand this, in order to provide the time and money to do the job properly.

You will never get everything right first time, and you can never know exactly what ‘finished’ looks like at the outset.

Look at any popular app in the App Store, or on Google Play - what version is it on? How many previous releases were there, over what timeline? How many of those releases were bug fixes, new features, or both? Perhaps more importantly, consider how long it took and how much it really cost to get to the latest version.

If you’re appointing a developer to build you a new app, they will almost certainly be quoting to build you version 1.0 - so you need to budget for version 2.0, because version 1.0 will never be sufficient.

An app isn’t a milestone; it’s a roadmap, a journey, an ongoing relationship with customers and their changing demands. 

It’s also a commitment - when new operating systems and devices are released, often several times a year, you will need to cater for these - so ongoing support, and the cost of it, must be considered.

Most projects will be delivered using an ‘Agile’ approach, where features will be scoped, estimated, and prioritised. Inevitably your budget will run out at some point, but by this point you will have included the most important features, and made them as good as can be. This is often called your Minimum Viable Product (MVP). The remaining features that don’t make the MVP release are then prioritised and become part of the future delivery roadmap that you’ve hopefully also budgeted for.

Most apps are more than just an app. There is the ‘front end’, the bit your customer will see, and there will likely be many other aspects they do not; integrations between websites, CRMs, payment providers, third-party systems, etc. 

Many app projects require some form of back-end ‘application’ to be built, and integrated with these systems; administration interfaces (and logins) will be created for staff to manage user accounts, and other information within the app that will change frequently.

This ‘other information’ is likely to contain sensitive data, which will be affected by GDPR (and possibly PCI) compliance. It must be safely (and justifiably) stored, securely transmitted, and safeguarded by internal policies.

This is where you quickly begin to differentiate between developers -  those who just build what you ask - and those who really know their onions, who become your trusted advisor.