Restaurant app: is it worth building one?

A restaurant app is a piece of software a customer installs on their phone. Building one is a common ambition and, for most independent restaurants, a bad first move.

This is not a technical argument. It is about what an app requires from your customer, and what it requires from you every year afterwards.

The install problem

Everything an app does well happens after installation. Everything hard about an app happens before it.

A customer who wants to order from you tonight has to find your app in a store, decide it is worth the space, wait for it to download, and often create an account. Every one of those steps loses people. A web page asks for none of them.

Then there is keeping it. Phones fill up, and the apps that get deleted are the ones opened least. A restaurant that a customer visits twice a month is a strong candidate for deletion, however good the food is.

"Owners ask us to build an app because the big chains have one. The chains are ordering from thousands of people every day. Getting somebody to install software for a place they visit twice a month is a completely different problem."

— Tanzeel ur Rehman, co-founder of Get Menu

What you take on, every year

An app is not a project that finishes. Both stores require ongoing participation.

Apple requires you to be enrolled in its Developer Program to distribute an app, and every submission is judged against its published App Store Review Guidelines. Google Play similarly requires a developer account and registration.

That means, for as long as the app exists: enrolment maintained, updates when the operating systems change, review when you submit, and a policy landscape that moves without asking you. A small restaurant does not usually have a person for that, so it becomes a supplier relationship you cannot leave, on a product only a fraction of your customers ever installed.

What a digital menu on the web does instead

The alternative is not a worse version of an app. For most restaurants it is a better fit for the actual behaviour.

A code on the table or the window opens a page. Nothing to install, nothing to update, nothing to review, and it works on the phone the customer is already holding.

• A stamp card your regulars actually keep, with tiers that carry their own automatic discount, held in the phone's wallet through Google's loyalty card format.
• A PDF tax invoice with your registration number on it, downloadable by the customer without logging in.
• Table routing. The code already carries the table, so nobody has to write a number down.
• Everyone orders separately, the group pays once: one bill, many phones.
• Coupons that carry caps, exclusions and an expiry, upsells at the right moment, and bundles, with automatic discounts that never stack.
• A whole menu from one spreadsheet, uploaded in a minute rather than typed over an evening.
• Your own ordering page, in any of 12 page layouts, so the menu reads the way you want it to and the link carries your name.
• A menu edited by you, not a vendor: options and add-ons carry their own prices, and required choices are enforced so the kitchen can trust the ticket.
• Checkout re-prices every line against the menu as it stands, so a price change takes effect on the next order, not the next week.
• The confirmation reaches the customer the moment they order, the ticket reaches the kitchen, and the rider gets a link with the pin dropped at checkout. 3 messages, about 2 seconds, nobody typing.
• Live stock on items and on options, counting down as orders come in and greying out what has gone, so nobody asks what is available.

The part that gets you most of what you wanted

The usual reason for wanting an app is a place on the customer's phone. There is a way to have that without an app.

A loyalty card added to the phone's own wallet sits alongside their boarding passes and tickets. It is on the device, it updates itself when they earn a stamp, and there is nothing to install and nothing to delete. For most restaurants that is the actual goal, reached without a developer account or a review process.

The honest test, before you commission anything

Ask yourself one question and answer it with a number rather than a feeling: how many of your customers would install it?

Not how many like you. How many would give space on their phone to a place they eat at twice a month. Write the number down before anyone quotes you.

Then run the cheap version of the experiment first. Put a code on 8 tables and in your window for a month, and count how many people order through it. That is your ceiling for app installs, and it will be a good deal higher than the app number, because the page asked nothing of them.

If the web number is small, an app will be smaller. If the web number is large, you now have a real figure to judge an app against, which is a much better position than the one you are in today.

When an app genuinely makes sense

To be fair, there are cases:

• A group with several sites and daily order frequency, like a coffee chain.
• A business where the app is the product rather than a convenience, such as a subscription or a members club.
• An operator with an in-house team already maintaining software.

If none of those describe you, build the web ordering first. It costs an afternoon, and if it works you will have real numbers to judge an app against later, which is a far better position than guessing now.

What we do not do

Get Menu is not an app builder and does not publish an app to the stores in your name. It is a web ordering page, a menu, stock, messaging and loyalty, working in the browser the customer already has.

It is also not a restaurant management system in the full sense: no register, no rotas, no payroll. Payment is cash or your own card machine at the door or the table, with no online payments in the system, which means no card details are held in it, and old order details clear automatically after 120 days.

Pricing sits on the pricing page rather than in this article, and the trial runs 15 days with no card.

Frequently asked questions

Do I need a restaurant app?

Most independent restaurants do not. The hard part is not building it, it is getting somebody to install it and keep it for a place they visit twice a month.

What does an app cost to keep going?

Beyond the build: store enrolment maintained every year, updates when the operating systems change, and a submission reviewed against published guidelines each time. Those are ongoing commitments rather than one-off costs.

Is a digital menu as good?

For ordering, usually better, because there is nothing to install. A code opens the page on the phone the customer is already holding.

Can I still be on their home screen?

In effect, yes. A loyalty card added to the phone's wallet lives on the device and updates itself, with nothing to install.

How do customers pay?

Cash or your own card machine when the food arrives. There are no online payments in our system.