Ramen Joe started as a single restaurant in Lisbon. Today it runs five houses, an iOS app on the App Store, an Android app on Google Play, a loyalty program with Apple Wallet and Google Wallet, and a back office that runs the group's operations. All of it sits on one platform.
This piece covers what that platform solved, what it cost to build instead of buying off-the-shelf SaaS, 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 hits three technical problems nobody sizes correctly at the start. Fragmented reservations per house. A loyalty program that fails to follow the customer between locations. Operational data that lives in local files and WhatsApp threads.
Ramen Joe consolidated the operation into one system. Shared reservations, single customer identity, loyalty, digital menu, staff management, and centralized analytics. In practice, a customer who stamps their card in Lisbon sees the same balance in Porto, while the team runs five houses — and can add new locations — from the same back office.
The cost of this choice is not trivial. But the cost of not making it shows up later, disguised as churn, staff doing duplicate work, and expansion decisions made in the dark.
The business problem
When a single restaurant turns into a group, the software that served one house well starts to crack. Not because it's bad. Because it was designed for a context that no longer matches yours.
The classic symptom: each location ends up with its own reservation module, often tied to Google or a specific SaaS tool. Loyalty customers live in a database per house, or worse, in a paper notebook. When you ask how many recurring customers the group has, there's no answer. Only estimates.
Here's the critical point. In one house, the CRM is the manager. He knows the regulars, knows who prefers the back table, knows who brings the family on Sundays. Across five houses, that distributed memory breaks down. And the customer notices.
Why this matters
Loyalty in hospitality is not an operational detail. It's 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 in almost every sector, and hospitality is no exception.
If your loyalty program does not follow the customer between locations, you're treating every visit as if it were the first. It isn't. The customer remembers. The system doesn't.
The second angle is operational. A group with five houses generates enough data to make informed business decisions. Which time slots fill up first. Which weekdays 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
Ramen Joe's 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 mirror the site experience in a mobile context.
The choice to build native apps rather than a PWA deserves an explanation. It wasn't technical vanity. It was a product decision driven by three concrete things.
- Apple Wallet and Google Wallet integrate cleanly with native apps — the loyalty card goes straight into the phone's wallet and receives automatic updates when the balance changes.
- Push notifications on iOS have restrictions that the web can't work around without hurting the experience.
- Staff tap-to-scan in restaurants needs a camera with fast autofocus and near-zero latency. The web still loses here.
On the reservations side, the system is decoupled per house calendar. When a customer books in Lisbon, only the Lisbon table is blocked. But the customer record, the history, the seating preference — all of that is global.
Digital menu and expansion without technical dependency
The platform also centralizes the digital menu for all five locations. The team manages products, information, and each house's configuration in the same back office, keeping the experience consistent across the site and the apps without duplicating work per channel.
Multi-location management was designed so that group expansion doesn't require a new technical intervention. The team itself can register a location, set hours, contacts, menu, tables, reservation rules, and the remaining operational settings.
Once configured, the new house becomes available on the site and in the mobile apps from the same data source. There's no need to build a new version of the site or the apps just to add a unit. That reduces the cost and the time between the expansion decision and the new location going live across digital channels.
Cross-location loyalty is the decision that changes everything
The most common friction point in restaurant groups is this. Each house wants its own program. Each manager wants to see their own loyal customers. And every marketing campaign tends to get stuck at a single location.
Ramen Joe went the other way. One program, one point wallet, one customer. This has non-trivial accounting implications — who "pays" for the stamp given in Lisbon and redeemed in Porto? — but it's solved with internal allocation rules, not by fragmenting the system.
The customer shouldn't have to think about any of this. And, honestly, they don't. Install the app once, add the card to Wallet, and the experience is the same at any house in the group. That's loyalty product-market fit.
The role of staff
A digital loyalty system only works if staff cooperate. If the stamping process takes longer than the old routine of pressing a physical stamp on a paper card, staff will sabotage it — not out of ill will, but out of overload during peak hours.
Ramen Joe's scanner was designed with this constraint in mind. Logged-in staff open the app, point the camera at the customer's QR code, and the stamp is applied in under two seconds. No menus, no intermediate confirmations, no typing.
The permission to hand out stamps is separated from the permission to access the back office. A waiter stamps. A manager reads reports. A group administrator changes rules. This separation is standard in enterprise SaaS, but it's often ignored in restaurant software — and then people wonder why there was internal fraud with points.
Reservations: less automation, more control
Any modern reservation system faces a temptation: automate everything. Automatic confirmation, automatic reminder, automatic response to changes. And, in most cases, it works fine.
In quality hospitality, it works less well. A twelve-person reservation on a Saturday night shouldn't be auto-confirmed without someone looking at the dining room. A specific-table request should be seen by someone who knows the house. And last-minute exceptions need a human.
Ramen Joe's platform allows both models, house by house. Standard reservations are automatic. Large reservations or those with special requests enter an approval queue. And there's an SMS channel via Telnyx that sends reminders one hour before the reservation, which reduced no-shows without generating spam.
The SMS is short by design. Name, time, house. 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 reservation volume. It's not a technical limit: capacity can be adjusted as the operation grows.
The apps: iOS and Android launched together
The iOS and Android versions launched together. The Android app became available later because Google Play's review process took longer, not because of a decision to phase the product or favor one platform.
Both apps were built in parallel, with the same value proposition: reservations, loyalty, and a consistent experience across both platforms. The gap in store visibility came down to marketplace approval timing, nothing more.
The cost is obvious: two native codebases instead of one 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 it to, 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. They're worth naming.
- They start with the app. Without a mature backend and clear business rules, the app becomes a pretty shell that mirrors operational chaos on mobile screens.
- They rely on WordPress plugins for reservations and loyalty. Works for one house. Breaks at five.
- They hire agencies that build per project and disappear. Software doesn't end at launch. That's where it starts.
The antidote for all three is the same. Treat software as infrastructure, not as a campaign. Invest first in foundations — backend, database, authentication, permissions, continuous deploy — and only then in the visible surface.
Good practices that paid off
Some decisions look minor but had an outsized impact on how the system behaves in production.
First: git as the single source of truth. Every change goes through a commit, every deploy is automated via GitHub Actions. This eliminates the category of "works on my machine" bugs and lets you roll back in minutes if something breaks in production. GitHub's official documentation on continuous deployment covers the principles well.
Second: internationalization done properly. The site works in Portuguese and English, with strings centralized in translation files. This looks like overkill for a Lisbon restaurant, until you realize that 30% of customers in tourist zones don't speak Portuguese. And that expanding to a new city is easier when the system already supports multiple languages.
Third: separating sandbox from production with clear rules. Ramen Joe runs a sandbox version that mirrors production but with test data. Every change goes through there first. This lowers the odds of breaking a real reservation while testing a new feature.
Where this model applies
Ramen Joe's architecture is not specific to ramen. It applies to any retail or hospitality business with multiple locations and a recurring customer base. Restaurant groups, coffee chains, barbershop networks, clinics with multiple sites, gyms with more than one branch.
The common denominator is this: the customer is a single person, but the operation is distributed. If your software doesn't reflect that, you're paying in operational friction what you should be earning in loyalty.
Key takeaways
- A restaurant group with multiple houses needs a unified platform — fragmented reservations cost more than the software to consolidate them.
- A genuinely multi-location platform lets the team register new locations, menus, and operational rules without asking for technical changes to the site or the apps.
- Cross-location loyalty is not optional if you want real retention. The customer doesn't care which house they spent money at.
- Native apps justify themselves when Wallet, push notifications, and a fast camera are core to the experience.
- Staff are users of the system as much as the customer is. 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's measuring. Which stamps convert into a second visit. Which houses retain best. Which campaigns actually move the needle. A unified platform makes that analysis possible. From there, it's a matter of looking.