Anyone who wants an app developed usually has a clear picture of the screen: what the user sees, where they tap, what happens next. That is a good start. But an app is more than its screens: there is a server holding the data, an admin area where you manage content and users, accounts with Apple and Google, and someone who keeps the app up to date after launch.

This article describes the order in which an app comes about, which decisions come up along the way and how to tell that a project has been set up well.

One note first: this is about apps that are a product in their own right - an app for your customers, members or partners. If the app is mainly meant to support your own operations, for field technicians or the warehouse for instance, the article on capturing orders on a phone is the better read.

Step 1: Understand the idea and the users

Three questions come first: who uses the app? What must it be able to do on day one? And how does your business benefit - through sales, subscriptions, more revenue elsewhere, or because calls and paperwork go away?

That produces a list of features. The list is almost always too long. The real work in this step is cutting it down: what does the first version need so that people use it and you learn something from it? What deliberately comes later? How to test an idea before a lot of money goes into it is covered in testing an app idea.

At the end of this step there should be a short document: the users, the main journeys through the app, what happens in the admin area and what the first version explicitly does not do.

Step 2: Settle the fundamental questions

Before anyone starts developing, a few basic questions need answers:

  • Which devices? iPhone, Android, tablet, browser - or a selection of them.
  • Native app or web app? An app from the store can do more, a web app is quicker to distribute. The difference is explained in native app or web app.
  • Sign-in: do users need an account? With email and password, with Apple or Google sign-in, or none at all?
  • Payment: do users buy anything in the app? Digital content and subscriptions generally go through Apple’s and Google’s own payment systems, physical goods and services usually through a separate payment provider.
  • Connections: does the app need to talk to existing systems such as a till, a shop or an inventory system? Whether and how that works depends on the system and is best checked early, where possible.

These decisions shape the effort far more than the number of screens.

Step 3: Design and develop

Now the screen designs take shape, and alongside them the parts nobody sees: the server with the data, the sign-in, the admin area. Good developers show you something tangible early on - a test version on your own phone rather than a slide deck.

Your job as the client in this step: try things out regularly and give feedback. Ask when something looks different from what you expected. The earlier a deviation is spotted, the smaller it is.

Step 4: Test with real users

Before the app goes into the store, people who did not plan it should use it. Apple and Google both offer ways to distribute a test version to a limited group. Testing happens on the devices your users actually own: older phones, small screens, a poor signal.

What turns up is rarely a bug in the narrow sense. More often it is a place where users get stuck: a button nobody finds, a term nobody understands. How an acceptance test works in practice is described in acceptance and test environment.

Step 5: Publish

Every app in the Apple App Store and on Google Play is reviewed before it is published - and so is every later version. You need developer accounts, a privacy policy, details of what data the app uses, screenshots and a description. What exactly is required is covered in publishing an app in the stores.

One thing matters already at this point: the accounts should be in your company’s name, not the developer’s. Otherwise the app in the store does not ultimately belong to you. More on this in who owns your software?

Step 6: Run and develop further

Publishing is where the work really starts. Apple and Google release new versions of their operating systems every year, and the app has to run on them. The stores change their rules. Users report bugs and ask for features. The server needs updates and backups.

Plan for this from the start, both in your organisation and in your budget. An app that is no longer updated will eventually fail on new devices or disappear from the store.

What drives the effort

There is no flat rate for “an app”. The effort depends mainly on:

  • the number of user groups and their permissions
  • whether there is an admin area and how much it has to do
  • payments, subscriptions and invoices
  • connections to existing systems or devices
  • content such as videos that has to be stored and delivered
  • how much needs to work offline

How a reliable estimate is put together is described in how a software estimate is made.

How to recognise a good developer

  • They ask about your users and your business first, not about colours and fonts.
  • They suggest what the first version can leave out.
  • They show a test version on real devices early.
  • They raise the subject of running the app after launch without being asked.
  • The Apple and Google accounts are in your name.
  • You have one fixed contact rather than a different person for every question.

Questions before the first conversation

  • Who exactly should use the app, and why would they install it?
  • What must the first version do - and what not?
  • How does your business benefit from the app?
  • Which existing systems or devices does it need to reach?
  • Who on your side looks after content and user questions once the app is live?

With these answers, a first conversation with a developer is far more productive - and the first version considerably smaller.