Mobile apps: the weight and the asks decide more than the features

This article is for somebody who has already settled the previous question: an app really is the right answer, the use is repeated, people know you. So it will not reopen that debate.

It deals with what comes next and actually decides the project’s fate. An app is almost never abandoned for what it does badly; it is abandoned before that, in the two minutes between deciding to download and using it for real.

Those two minutes contain three obstacles that development treats as technical details and the user experiences as questions: how much data is this going to cost me, why do I have to create an account, and why are you asking for that.

Three decisions, taken in the first weeks of a project, and more or less impossible to undo afterwards. That is this article’s subject, and it is why it says so little about features.

Requiring an account before any use is the decision that costs the most users, and it is nearly always taken for good internal reasons.

It is defended by the need to know your users, to synchronise, to secure. All of those are real and none justifies putting the request on the first screen, before the person has seen what they get.

The question to ask feature by feature is: does this one need to know who this person is? Browsing a catalogue, opening times, a map, availability: no. Placing an order, seeing a history, receiving something: yes.

So the right architecture is in two stages and takes a little more work: everything that is browsed stays open, and the account is requested at the exact moment it becomes necessary, with the reason shown next to the request.

One case common in Algeria deserves naming: sign-up by phone number with a verification code. It is lighter than a password and it has a real cost — a message that does not arrive is a user lost with no recourse. Always provide a second attempt and another channel. That is three days of development and it recovers people who otherwise had no way of telling you.

The usual debate is about technology: one shared codebase or two separate apps. That is a real question and it is not the first one.

The first is whether both are needed at all. Many projects launch on both platforms out of symmetry when their audience is overwhelmingly on one — which doubles the cost of building, testing and above all maintaining, for a fraction of the users.

The answer is not guessed, it is read: your website has been telling you for months which platform the people who visit you are on. It is data you already have and nobody looks at before deciding.

On the technology itself, the deciding rule is hardware use. An app that displays, captures and sends works perfectly well on a shared codebase; one that heavily uses the camera, the sensors or the background ends up paying dearly for its intermediary.

And there is a cost quotations nearly always omit: each platform has its own publication process, rules and review delays. That is not development, it is recurring administration, and it belongs in the annual budget. It is counted in days per year and it never goes away.

Between deciding to look for your app and installing it there is a page you do not write yourself, or rather one you write without thinking: the store listing.

It carries four things that decide: the name, the first sentence, the first images, and the size. The rest of the text is read by a minority and mostly serves to be found.

The images are what actually gets looked at, and the common error is putting raw screenshots there. What has to be shown is what the app lets somebody do, in the order they will do it, with one word per image. Four images built that way beat eight faithful screenshots.

The name matters more than people think because it is searched for. A brand name alone assumes you are known; a brand name followed by what the app does is found by both audiences.

Finally, store reviews follow the same rules as everywhere else in this series: they are written by people something happened to, the useful reply is short and factual, and the right moment to ask for one is straight after a successful action — never at launch.

What we will refuse: putting account creation on the first screen. We know it simplifies the architecture and fills a user base faster; it is also the decision that loses the most people, and we would rather build the two-stage opening.

We will also refuse to ask for a permission at startup. Each will be requested at the moment of use, with its reason shown, and refusal will be handled as a normal path rather than a fault.

And we will refuse to ship an app without a written annual maintenance budget. An app without maintenance does not degrade slowly: it stops being installable, and you will hear about it from a customer.

What we do: a weight ceiling fixed before the first line, a first opening that shows something useful before asking for anything, defined behaviour for a slow, lost and restored connection, publishing accounts in your name, and a written distinction between updates that add and updates that are the price of staying online.

And what you should do without us this week: look in your website statistics at how your visitors split between the two mobile platforms. It is free, the data has existed for months, and it may tell you that you need only one of the two apps you were about to have priced.