Installs are the vanity number. The whole game is whether the app gets opened a second time, four weeks later, when the novelty is gone and the icon has drifted onto the third screen behind a banking app and a game. Topic 1 put the honest figure on it: fewer than half survive the first month. This topic is about the few things that genuinely move that number, and the one that quietly destroys it.
🔁 A reason to open it, in one sentence
Ask yourself what a customer gains by opening your app instead of phoning you or typing your name into a browser. If the answer takes more than a sentence, there is no reason, and no amount of design will manufacture one.
There are only a handful of answers that work in a restaurant, and they are all concrete.
- My usual, in two taps. The best of them, and the reason topic 3 suggested building version one around reordering. It beats a phone call on speed, which is the only fair comparison.
- Points I can see. A balance that visibly moves after every visit is a reason to open the app while standing at the counter. The programme behind it is the loyalty course's job; the app is only the window.
- Skip the queue. Order-ahead genuinely earns an install in a place with a lunch rush, because the customer gets time back.
- Something only the app has, and it must be real: a table held for regulars, a dish that appears there first, a price that exists nowhere else. If the offer is also on the website, the app has no argument.
What does not work, in any restaurant, is "news" — an app whose reason to exist is that it will tell you things. That is what the email list is for, it is cheaper, and the email course already built it.
🔔 Notifications, honestly
Push notifications are the one capability an app has that a website does not, and they are also the fastest way to get deleted. Both facts are true at once, and the difference between them is entirely about restraint.
The rules that keep an app installed are simple. Fewer than you want to send — for a restaurant, roughly two to four a month is the ceiling, not the target. Only when there is something specific: the table is ready, the order is on its way, the points reached a reward, the thing they always order is back on the menu. Never at bad hours, and never on a Sunday morning. And always with a way out that is not deleting the app — a settings screen where somebody can turn off the marketing ones and keep the order updates.
The distinction in that last sentence is the important one. There are two kinds of notification and they should never be mixed: transactional ones the customer asked for by placing an order, and marketing ones you decided to send. Getting the second kind wrong makes people turn off the first kind, and then your order-ready message stops arriving — which is a service failure caused by a marketing decision.
📲 Getting installs in the first place
Nobody discovers a single restaurant's app by browsing a store. Every install a small restaurant gets comes from somewhere physical or from a channel it already owns, and the ones that stick come with a reason attached.
What works is a person saying a specific sentence at the moment of payment: "if you install this, your next coffee is on us and your usual order is one tap." What also works is the same offer on the check, on a small card, on the door, and in the email list you already have — the email course is the cheapest install channel a restaurant owns, because it reaches people who have already decided they like you.
What does not work is a QR code with the word "app" under it and nothing else, or paying for downloads. An install without a reason is an install that gets deleted in the first clean-up, and you paid for it twice: once to acquire and once in the retention number that makes your app look worse than it is.
🔐 The data is the actual asset
Whatever happens to the app, the thing worth keeping is the list of people and what they ordered. That is the customer data course's subject, and this is where an app either contributes to it or quietly withholds it.
Make sure of three things. That every order in the app lands in the same customer record as the phone order and the online order, so a regular is one person and not three. That you can export the whole list — names, contacts, order history — on your own, at any time, which was the contract clause in topic 3. And that you are only collecting what you will actually use, because the data laws the customer data course covers apply exactly the same on a phone as anywhere else, and an app that harvests location because the provider offers the feature is a liability with no upside.
This matters even more than usual here, for a reason topic 6 makes concrete: the app is the most likely thing in this library to be switched off within two years. If everything it learned about your customers goes with it, you paid for a channel and kept nothing. If the data lives in your own list, then even a failed app leaves you better off than you started.