An app, or a bettermobile website.

The test

Frequency, value,convenience.

Three quantities decide whether a mobile product earns its cost, and they multiply rather than add. A near zero in any one of them takes the whole product to near zero, which is why a high score on the other two is not a rescue.

1. Frequency, taken from a system rather than from a guess

   How many times a year does one customer, or one member of staff, perform the action the app is being built around? The answer is in the order table, the booking calendar, the job records or the call log. Take a year, divide by the number of distinct people, and use the median rather than the mean, because a handful of very frequent users will otherwise carry the whole case.

2. Value, taken from margin or from cost

   For a customer-facing action, the gross margin on one occurrence. For an internal action, the fully loaded cost of performing it the current way, which includes the person who is interrupted as well as the person doing it.

3. Convenience, measured in steps

   Count the steps and the seconds today, and count them in the proposed design. A reorder that goes from eleven steps to two is a product. A reorder that goes from four steps to three is a preference. This is the term most often asserted and least often measured, and it is the cheapest of the three to establish.

4. Then the two terms that decide the answer

   Multiply the three, and then multiply by the number of people who will install it and the share of those still using it after three months. The second of those is the number nobody has. It is also the number that most often turns a confident business case into a marginal one, which is why the next section is about measuring it cheaply rather than estimating it confidently.

5. And the denominator, in full

   The build, plus two store submission and review cycles, plus maintaining two platforms, plus the annual operating system releases that will require work whether or not anything has been added, plus the support channel for people who cannot sign in. An app is a subscription to an obligation, and pricing it as a one-time build is how apps end up abandoned at version 1.2.

The category nobody counts

The best mobile productsare never in a store.

The strongest mobile case in an established business is usually not a consumer app at all. It is the tool a field crew, a warehouse team, a delivery fleet or a sales force uses every working day, and it wins the test on all three terms at once: the frequency is daily, the value is the cost of the current paperwork, and the convenience difference between a phone and a clipboard is large.

It also removes most of what makes a consumer app expensive and risky. There is no store review, because it is distributed through a device management system or an internal link. There is no install problem, because using it is part of the job. There is no platform split, because the organisation decides which devices it buys. There is no marketing cost, and there is no retention question, because the user is paid to be there.

What it does bring instead is a harder engineering requirement that consumer apps rarely face: it has to work where there is no signal. A crew in a basement, a driver in a rural township or a technician inside a steel building all need the work to be captured now and synchronised later, which means conflict handling, a queue that survives the app being closed, and a clear rule about what happens when two people edited the same job. That is real work, and it is the part of an internal build worth scrutinising in a quote.

Questions

Questions peopleactually ask.

• Do we need to be in the app store to look serious?

  Store presence is a distribution channel, not a credibility signal, and an app with no reviews and no recent updates reads worse than no app at all. If the reason for building is that a competitor has one, the test in this article will usually return a number that settles the question either way, which is a better argument than either instinct.

• Will our customers install it?

  That is the number nobody has, and it is the one worth measuring rather than assuming. The cheapest measurement is an installable web version of the single most valuable action: it can be added to a home screen, it costs a fraction of a native build, and the install count is a real signal about a real audience rather than a projection.

• Do we have to build for both iOS and Android?

  Usually yes for a consumer product, because the split in Canada is close enough that ignoring one platform removes a large share of the audience. For an internal tool the answer is often no, because the organisation controls which devices its people carry, and building for one platform halves the work and the ongoing maintenance.

• Can one codebase serve both platforms?

  Yes, and it is the usual answer for a product whose value is in its workflow rather than in device performance. A shared codebase still pays for two store submissions, two review processes and two sets of platform conventions, so it reduces the build cost substantially and the running cost by less than people expect.

• What happens if nobody opens it twice?

  Then the value was in frequency and the frequency was not there, which is exactly what the test is designed to find out before the money is spent. The recovery is not more notifications. It is to look again at whether the action the app was built around is one people actually perform often, and to move the effort to the surface where they already are.