Ramen Joe started as a single restaurant in Lisbon. Today it runs five venues, an iOS app on the App Store, an Android app on Google Play, a loyalty programme wired into Apple Wallet and Google Wallet, and a back office that runs the group's operations. All of it sits on one platform.
This piece sets out what that platform solved, what it cost to build rather than buy off the shelf, and where most restaurant groups get it wrong when they try to do the same.
Executive summary
A restaurant group with more than two locations typically has three technical problems nobody sizes well up front. Bookings fragmented by venue. A loyalty programme that does not follow the customer between shops. Operational data that lives in local files and WhatsApp threads.
Ramen Joe consolidated the operation into a single system. Shared bookings, a single customer record, loyalty, digital menu, staff management and centralised analytics. The practical outcome is that a customer stamping a card in Lisbon sees the same balance in Porto, while the team runs five venues — and can add new ones — from the same back office.
The cost of this choice is not trivial. But the cost of avoiding it turns up later, disguised as churn, staff repeating work, and expansion decisions taken blind.
The business problem
When a single restaurant becomes a group, the software that served one venue well starts to break. Not because it is bad. Because it was designed for a context that no longer fits you.
The classic symptom: each location ends up with its own bookings module, often bolted onto Google or a specific SaaS tool. Loyalty customers live in a per-venue database, or worse, a paper notebook. When you want to know how many repeat customers the group has, there is no answer. Only estimates.
Here is the critical point. In a single venue, the CRM is the manager. They know the regulars, know who prefers the back table, know who brings the family on Sundays. Across five venues, that distributed memory stops working. And the customer notices.
Why this matters
Loyalty in hospitality is not an operational detail. It is the backbone of the model. The cost of acquiring a new customer is several times higher than the cost of bringing an existing one back. This holds across nearly every sector, and hospitality is no exception.
If your loyalty programme does not follow the customer between shops, you are treating every visit as if it were the first. It is not. The customer remembers. The system does not.
The second angle is operational. A group with five venues generates enough data to make informed business decisions. Which time slots fill first. Which days of the week need campaigns. Which location has the most no-shows. Without a single platform, that data exists but nobody can read it.
What the platform does
The Ramen Joe architecture rests on three blocks that talk to each other. An Express backend with a relational database, a public Next.js frontend for end customers, and a set of native apps (iOS SwiftUI and Android) that replicate the site experience on mobile.
The choice of native apps over a PWA deserves an explanation. It is not technical vanity. It was a product decision driven by three concrete factors.
- Apple Wallet and Google Wallet integrate cleanly with native apps — the loyalty card goes straight into the phone's wallet, and updates automatically when the balance changes.
- Push notifications on iOS have restrictions the web cannot work around without hurting the experience.
- Staff tap-to-scan in restaurants needs a camera with quick autofocus and near-zero latency. The web still loses on this one.
On the bookings side, the system is desynchronised from each venue's calendar. When a customer books in Lisbon, the table is locked only in Lisbon. But the customer record, the history, the seating preference — all of that is global.
Digital menu and expansion without technical dependency
The platform also centralises the digital menu across the five locations. The team manages products, information and each venue's configuration from the same back office, keeping the experience consistent on the site and in the apps without duplicating work per channel.
Multi-location management was designed so that group expansion does not depend on further technical work. The team itself can register a location, set opening hours, contacts, menu, tables, booking rules and the rest of the operational configuration.
Once configured, the new venue becomes available on the site and in the mobile apps from the same data source. There is no need to develop a new version of the site or the apps just to add a unit. That cuts the cost and the lead time between the expansion decision and the new location going live across digital channels.
Cross-shop loyalty: the decision that changes everything
The most common friction point in restaurant groups is this. Each venue wants its own programme. Each manager wants to see their own loyal customers. And each marketing campaign tends to stay locked to one location.
Ramen Joe went the other way. One programme, one point balance, one customer. This has non-trivial accounting implications — who "pays" for a stamp given in Lisbon and redeemed in Porto? — but it is solved with internal allocation rules, not by fragmenting the system.
The customer should not have to think about it. And, honestly, they do not. They install the app once, add the card to Wallet, and the experience is the same at any venue in the group. That is loyalty product-market fit.
The role of staff
A digital loyalty system only works if staff play along. If the stamping process takes longer than the old routine of pressing a stamp onto a paper card, staff will sabotage it — not out of ill will, but because peak hours overwhelm the extra steps.
The Ramen Joe scanner was designed with that constraint in mind. A logged-in staff member opens the app, points the camera at the customer's QR code, and the stamp is granted in under two seconds. No menus, no intermediate confirmations, no typing.
The permission to grant stamps is separated from the permission to reach the back office. A waiter stamps. A manager sees reports. A group administrator changes the rules. This separation is standard in enterprise SaaS, but it is often ignored in hospitality software — and then people wonder why internal points fraud happens.
Bookings: less automation, more control
Every modern booking system tempts you to automate everything. Automatic confirmation, automatic reminder, automatic response to changes. In most cases, it works well.
In quality hospitality, it works less well. A twelve-person booking on a Saturday night should not be confirmed automatically without someone looking at the room. A request for a specific table should pass through someone who knows the venue. And last-minute exceptions need a human.
The Ramen Joe platform supports both models, venue by venue. Standard bookings are automatic. Large parties or special requests enter an approval queue. And there is an SMS channel through Telnyx that sends reminders an hour before the booking, which cut no-shows without generating spam.
The SMS is short by design. Name, time, venue. A link to cancel. Nothing else. The commercial package was sized with an initial estimate of 1,500 SMS per year, calculated from the expected booking volume. It is not a technical ceiling: capacity can be adjusted as the operation grows.
The apps: iOS and Android released together
The iOS and Android versions were released together. The Android app went live later because Google Play's review process took longer, not because of any decision to phase the product or favour one platform.
Both apps were developed in parallel, with the same value proposition: bookings, loyalty and a consistent experience across the two platforms. The gap in store availability was only a matter of each marketplace's approval timing.
The cost is clear: two native codebases instead of a cross-platform framework like React Native or Flutter. It was a conscious trade-off. The gain is an app that behaves the way the platform asks for, not the way the lowest common denominator allows.
What goes wrong in these projects
Most restaurant groups that try to build a platform like this make the same three mistakes. It is worth naming them.
- They start with the app. Without a mature backend and clear business rules, the app becomes a pretty shell that replicates the operational chaos on mobile screens.
- They rely on WordPress plugins for bookings and loyalty. Fine for one venue. Falls apart at five.
- They hire agencies that build per project and disappear. Software does not end at launch. It starts there.
The antidote to all three is the same. Treat software as infrastructure, not as a campaign. Invest first in foundations — backend, database, authentication, permissions, continuous deployment — and only then in the visible surface.
Good practices that paid off
Some decisions look minor but had a disproportionate impact on how the system runs in production.
First: git as the single source of truth. Every change goes through a commit, every deploy is automatic via GitHub Actions. This kills the whole class of "works on my machine" bugs and lets you roll back in minutes if something breaks in production. GitHub's own docs on continuous deployment cover the principles well.
Second: proper internationalisation. The site works in Portuguese and English, with strings centralised in translation files. This looks like overkill for a restaurant in Lisbon, until you realise that 30% of customers in tourist areas do not speak Portuguese. And that expanding to a new city is easier when the system already supports multiple languages.
Third: separate sandbox from production with clear rules. Ramen Joe has a sandbox that mirrors production but with test data. Every change goes there first. This lowers the odds of breaking a real booking while testing a new feature.
Where this model applies
The Ramen Joe architecture is not specific to ramen. It applies to any retail or hospitality business with multiple locations and a base of repeat customers. Restaurant groups, coffee chains, barbershop networks, clinics with several branches, gyms with more than one site.
The common denominator is this: the customer is one, but the operation is distributed. If your software does not reflect that, you are paying in operational friction what you should be earning in loyalty.
Key takeaways
- A restaurant group with multiple venues needs a unified platform — fragmented bookings cost more than the software that consolidates them.
- A genuinely multi-location platform lets the team register new venues, menus and operational rules without asking for technical changes to the site or the apps.
- Cross-shop loyalty is not optional if you want real retention. The customer does not care which venue they spent at.
- Native apps are justified when Wallet, push notifications and a fast camera are central to the experience.
- Staff are users of the system as much as customers. If the flow takes longer than the old process, the system gets sabotaged by overload.
- Git as single source, sandbox separated from production, and i18n from day one. These are foundation decisions that avoid expensive refactors later.
- The most expensive mistake is starting with the app before the backend is mature.
The natural next step for a group at this stage is not adding more features. It is measuring. Which stamps convert to a second visit. Which venues retain best. Which campaigns actually move the needle. A unified platform makes that analysis possible. After that, it is a matter of looking.