A restaurant owner will occasionally ask us for a mobile app. Nine times out of ten, what they actually want is a URL they can send by text — one that opens fast, has today's menu, remembers a cart between visits, and doesn't require anyone to download anything from the App Store to place an order.
For Philliez, the American-inspired cheesesteak spot in Chester Hill, we ended up building exactly that: a mobile-first Progressive Web App with an app-like bottom nav (Menu · Directions · Order) and the same tap-through feel a native app would give — but installable in one tap and shareable in a single link. This post is the framework we used to decide, and why it's the same answer for most restaurants.
What a restaurant actually needs
Every restaurant we've built for eventually converges on the same four jobs the customer needs the site to do. In rough order of daily volume:
- See the menu, right now, quickly. Someone opened Google Maps, tapped through, and needs to decide in 20 seconds whether to keep walking or come in.
- Order for pickup or delivery. Usually late-night, usually one-handed, usually while doing something else.
- Get directions. Google Maps handoff, straight from the site.
- Call. Yes, still. Custom orders, catering enquiries, birthday reservations.
Notice what's not on the list: sign in, browse push-notification preferences, or download 40MB of shell before the menu shows. Every item on that list is discoverable via a single URL — which is the entire pitch for a PWA over a native app.
The decision framework: five questions
We use the same five questions whenever a client asks about a “mobile app.” If four or more come out on the PWA side, we build a PWA. If four or more come out on the native side, we build native.
- Does the app need background access to phone hardware? (Camera at rest, Bluetooth, precise GPS while backgrounded, accelerometer while the phone's asleep.) If yes → native. For a restaurant, no.
- Is there real repeat use? If the same customer opens the app 3+ times a week and would care about push notifications — a food-ordering platform or loyalty ecosystem might → native app conversation starts. A single-location restaurant's customer opens the site once every couple of weeks. → PWA.
- Is App Store discovery a growth channel? Almost never for a restaurant. Their discovery channel is Google Maps and Instagram, both of which are URL-first. → PWA.
- Is there a real financial argument for the ~50-70% revenue share on in-app purchases? Almost never for margin-thin food service. → PWA.
- Can the client afford to keep a native app updated? Every iOS release breaks something. A small restaurant does not want to be paying an engineer to maintain two app-store binaries in perpetuity. → PWA.
For Philliez, all five came out PWA. That's typical for a single-location restaurant.
What a restaurant PWA actually looks like
A PWA is not just “a website that opens on a phone.” The design decisions that make it feel like an app are all deliberate. For Philliez, the pieces that mattered most:
- App-style bottom nav — three tabs, always visible on scroll (Menu · Directions · Order). The moment a phone user sees a persistent bottom bar, they stop thinking of it as “a website.”
- One-thumb-reachable primary actions. The “Order” button is in the bottom-right of the screen at all times, exactly where a right-handed user's thumb rests. The call button and directions button follow the same logic.
- Installable, but not pushy. We do not throw a full-screen “install this app” interstitial. If the user comes back a second time, iOS and Chrome will offer the “Add to Home Screen” prompt themselves — that's a native platform thing. Fighting it feels manipulative.
- Offline-viewable menu. The menu markdown is cached the first time it's loaded. Even on a dodgy connection, the customer sees prices.
- Personality-forward voice. The site opens with a banner reading “⚠ Caution: Philly sauce is spicy.” That is the copy that makes a phone screen feel like an app, more than any framework decision does.
What you give up
Two things, honestly, and it's worth being straight about them:
- No push notifications on iOS unless the user installs the PWA. Since iOS 16.4 they're possible, but only after the user “Add to Home Screen”s the site. For a restaurant this is fine — you'd use SMS or email for order confirmations anyway.
- Less presence. You don't show up in a phone's app switcher unless the user installs. For most restaurants, this costs almost nothing. For a food-ordering platform, it costs a lot.
Neither of those things justifies the ongoing cost of maintaining a native binary in two app stores for a business that's opening physical doors, not selling subscriptions.
What a PWA does not fix
A great PWA does not save a bad menu, a slow kitchen, or a website with 8 seconds of splash-screen animation before the customer sees prices. About half of the work on Philliez wasn't PWA plumbing at all — it was cutting page weight, making the ordering flow reachable in three taps, and building a brand voice that felt like the shop rather than a template.
If you're a restaurant considering “an app,” the honest answer is almost always: you don't need one, you need a mobile website that feels like one. That's a PWA. And the difference in cost, distribution friction, and long-term maintenance is not close.