Restrofi started with a simple observation: Indian restaurants were paying heavy commissions to food-delivery aggregators for their own dine-in and takeaway customers, and juggling a stack of disconnected tools for ordering, billing, and marketing. We set out to build one platform that lets a restaurant take orders directly, run its floor, bill correctly under GST, and actually own its customer relationship. This is how we built it, and what it taught us about shipping real SaaS.
The problem we were solving
Walk into a typical mid-sized Indian restaurant and you will find a POS that does not talk to the kitchen, a separate billing book, a printed menu that is expensive to change, and no real way to bring a walk-in customer back. Meanwhile aggregator apps sit between the restaurant and its diners, taking a cut and owning the data. Restrofi's goal was to collapse that mess into a single self-serve product a restaurant could set up itself and run day to day — without a salesperson, an installation visit, or a training course.
QR ordering as the front door
The core interaction is deliberately frictionless: a diner scans a QR code at the table, sees a live menu, and orders from their own phone — no app to install, no waiting to flag down staff. Because the menu is digital, a restaurant can change prices, mark items sold out, or launch a combo instantly, which is impossible with print. That same QR-based flow extends to takeaway and, for properties like resorts and farmhouses, to room-based ordering that accumulates onto a folio and settles at checkout. Removing the app-install step matters more than it sounds: every install you require is customers you lose.
What sits behind the scan
A QR menu is the visible tip; most of the work is the operations platform underneath. Restrofi includes a point-of-sale, a real-time kitchen display so orders flow straight to the people cooking, GST-correct billing, and analytics that turn day-to-day orders into decisions about what to promote and when. We layered on the things restaurants actually asked for over time — combos and promo codes, loyalty, multi-outlet management for chains, and a WiFi captive portal that turns guest internet access into a marketing channel that grows the restaurant's own customer list rather than an aggregator's.
The architecture, and why
We built Restrofi as a Next.js and TypeScript application on MongoDB, with Razorpay for payments and a self-hosted deployment we operate ourselves. A few choices mattered:
- Server rendering keeps the marketing site fast and indexable while the app stays responsive on the mid-range phones diners actually use.
- A single codebase across the diner-facing menu, the staff dashboard, and the admin and superadmin tooling keeps development cost down and behaviour consistent.
- Self-hosting on our own VPS gives us control over cost and performance instead of being at the mercy of per-seat platform pricing — the same discipline we bring to client work.
- Configurability over hard-coding — menus, business types, order flows, and even whether staff can be called to a table are configurable, because a farmhouse resort and a quick-service cafe are not the same business.
Building for many kinds of restaurant
One of the harder lessons was that "restaurant" is not one template. A cafe, a fine-dine, a cloud kitchen, and a farmhouse all order, bill, and serve differently. Rather than fork the product into unmaintainable variants, we built a theming and layout system that re-skins the diner experience by business type and lets each outlet turn features on or off. That flexibility is what makes the same platform work for a single cafe and a multi-outlet chain — and it is far cheaper to maintain one configurable product than five hard-coded ones.
The hard parts
The genuinely difficult engineering was rarely the flashy bits. GST billing has real edge cases. Payments have to be reliable and reconcile correctly. Menus for large establishments can run to hundreds of items, which stresses both the import flow and the diner's page-load time, so performance and a smooth AI-assisted menu import mattered. And because a restaurant cannot stop taking orders when something goes wrong, the system has to fail gracefully rather than dramatically. None of that shows up in a demo, but all of it decides whether a restaurant keeps using the product after week one.
What shipping it taught us
Running Restrofi in production — not just demoing it — is where the real learning happened. The variety of how restaurants operate forced us to build something robust and configurable rather than pretty and rigid. It reinforced how we approach every product: ship a focused core, put it in front of real users, and let their needs drive the roadmap instead of guessing from a whiteboard. Features like room-based folios, WhatsApp add-ons, and managed payments all came from listening to what real operators needed next.
The takeaway
Restrofi is proof of how we like to build — a real, self-serve SaaS solving a concrete business problem, owned and operated end to end rather than assembled from other people's platforms. If you are a restaurant that wants to take orders directly and own your customers, Restrofi is live at restrofi.com. And if you are a founder who wants a product built and operated with the same care, that is exactly what we do at Navtechy.