SaaS & Startups · Web SaaS
MenuQR — Restaurant QR Menu SaaS
Multi-language digital QR menu platform with instant WhatsApp ordering & Stripe billing
Live SaaS
Active Status
The problem
Hospitality businesses required an affordable, contactless menu solution that eliminated printed menu costs while seamlessly converting table scans into direct WhatsApp orders without requiring app downloads. PDF QR codes were slow on cheap phones and could not take an order. A diner native app was off the table: guests will not install software to see tonight’s specials. The product had to launch the same day a manager could print a tent card.
Our approach
VyrroTech designed and launched MenuQR — a high-conversion SaaS platform with sub-second QR rendering, customer table ordering via WhatsApp, and automated vendor subscriptions powered by Stripe. Guests never create an account. Vendors edit menus in an admin they can run between services. Billing state lives in webhooks so a failed card cannot silently keep a venue live.
Engineered with Next.js App Router, Tailwind CSS, Node.js API routes, Stripe webhook engine, and localized i18n dynamic routing.
Why printed menus were the wrong product
Hospitality operators were paying for reprints every time a price or dish changed, then still losing orders to friction: a guest had to flag a waiter, wait, and hope the ticket reached the kitchen. Contactless QR PDFs were not an improvement—they were slow, unreadable on cheap phones, and could not take an order. The brief was an affordable SaaS that restaurants could launch the same day: scan, browse in the guest’s language, and send a structured order to WhatsApp without an app download. That constraint ruled out a native diner app and forced a web-first, sub-second menu render on mid-range Android devices common on café tables.
Product decisions that survived launch
We treated the guest path and the vendor path as two products sharing one platform. Guests never create an account. The QR encodes venue and table so the kitchen knows where the ticket belongs. Menu items, modifiers, and availability live in a vendor admin that non-technical managers can edit between services. Billing is Stripe subscriptions with webhook-safe state so a failed card does not silently keep a venue live. Multi-language copy is a first-class route, not a plugin overlay, because mixed Arabic/English menus are table stakes in GCC hospitality. Those choices kept the surface small enough to ship and honest enough to bill monthly.
Architecture and delivery
MenuQR is a Next.js App Router application with TypeScript, Tailwind CSS, and Node API routes. Stripe webhooks update subscription status independently of the UI so a refresh cannot double-charge. WhatsApp dispatch is a typed payload—table, items, notes—not a screenshot of the menu. i18n routing keeps language in the URL so search engines and share links stay coherent. Image and price fields are structured so a vendor edit invalidates only the affected cache, not the whole catalog. The same codebase serves marketing, guest menu, and vendor billing; we did not split three apps and hope they would stay in sync.
What we measured and what we did not invent
The product is live at getmenuqr.com with paying restaurants. Ordering method is WhatsApp API; checkout does not require a diner app. Recurring billing is Stripe. We do not publish vanity “orders per day” figures that we cannot stand behind on this page. What we will stand behind is the operating model: named delivery ownership, 100% IP on the platform code we wrote, and a 90-day bug warranty after launch. Subsequent work is product iteration—menu features, billing states, and performance—not a rewrite of the guest path that already converts table scans into kitchen tickets.
Lessons that transfer to other SaaS briefs
Zero-app checkout only works if the kitchen already lives in WhatsApp. If the operator’s workflow is a POS that cannot accept unstructured chats, the integration surface changes and we say so in discovery. Multi-tenant SaaS needs tenant filters on every query, job, and webhook—not only the UI. Content ops (menus) is the same problem as course catalogs or price lists: if non-engineers cannot edit facts, the product dies in Slack. MenuQR is also the nearest-fit public proof we cite for EdTech and other content-heavy SaaS: role-based admin, subscriptions, and a public surface that must stay fast. The vertical is hospitality; the pattern is multi-tenant product engineering.
What we would do differently on a second pass
A v1 SaaS that restaurants can launch the same day should stay small. If we were scoping MenuQR again, we would still refuse a diner native app, still refuse a kitchen KDS in version one, and still put Stripe state in webhooks rather than in the page. We would spend even more of week one on the vendor-admin empty states: what a manager sees when the menu is empty, when a card fails, when a language is missing a dish name. Those are the screens that determine whether a venue stays subscribed. For buyers comparing this case to a custom build, the transferable checklist is: guest path with no account, tenant isolation on every write, ops-owned content, and a billing state machine you can explain on a whiteboard. Everything else is a later milestone. Vyrrotech FZE still owns the product as a live SaaS; client builds that look like this get 100% IP of the code we write for them, a 90-day warranty, and a 2-hour response SLA on business days. If your brief is “QR plus WhatsApp plus subscriptions,” this is the engagement shape. If you need a full POS, say so before we pretend a chat ticket is a ledger.
Results
- Active Status
- Live SaaS
- Ordering Method
- WhatsApp API
- Payment Integration
- Stripe
Serving active paying restaurants
Zero friction customer checkout
Automated global recurring billing
Stack
- Next.js
- React
- Stripe API
- WhatsApp API
- Tailwind CSS
- TypeScript
- Node.js
In their words
“MenuQR revolutionized how our restaurant handles table orders. Customers scan and send orders directly to our WhatsApp kitchen terminal in seconds.”
Founder & Operator · MenuQR Partner
Services
Capabilities behind this build
FAQ
Working with VyrroTech — frequently asked questions
- Do clients own the code from projects like these?
- Yes. Clients receive 100% of codebase IP, schemas, and design assets upon milestone completion, plus a 90-day bug warranty after launch.
- How does VyrroTech run delivery on client builds?
- Named delivery lead, milestone-based sprints, staging demos, and written scope before billing. We prefer working software over slide-deck theater.
- Can you take on similar work in my market?
- We ship for operators across the US, UK, UAE, and Saudi Arabia from a UAE legal entity with UAE–Pakistan time-zone coverage. Share your outcome and constraints and we will be direct about fit.
Next step
Want results like this?
Tell us the outcome you're chasing — we'll tell you honestly how we'd get you there.