Skip to content

Portfolio · Food & Beverage · Web and mobile

One order record,and three ways into it.

A barbecue and biryani kitchen taking orders in the browser, at the desk and on the floor at the same time. Three surfaces sit on one API: a storefront a customer needs nothing installed to order from, an admin console the owner runs the menu, the offers and the day from, and an Android build the floor team carries. An order placed on the site is the row the console confirms and the phone marks ready — nothing is re-keyed between them.

The storefront home page, opening on a biryani over a dark field with one Order Now button under the headline.
The front door: a browser, a dish and one button. Nothing to install first.
01Sector
Independent restaurants — one kitchen, several channels
02Surfaces
Three — storefront, admin console, Android panel
03Behind them
One API, one menu, one order record
04Shipped
Signed Android build; an iOS target in the codebase, not submitted
Act 01/ 04Web1 capture

The storefront

The menu, in the browser.

The front door runs in a browser, so nothing stands between a hungry customer and a placed order: no install, no account before the menu. What makes it survive contact with a real kitchen is that almost nothing on it is code. The ranges, the dishes, the photographs and the prices are rows somebody in the restaurant owns, and the two things that change hourly — what is featured, and what has run out — are switches rather than edits.

The storefront menu with category chips over a grid of dishes, each card carrying a photograph, a name, a description and a price.
Chips generated from the console, so a new range is a row rather than a release.
  1. 01.01

    Categories the kitchen edits

    The chips over the grid come from the console, so adding a range never waits on a deployment.

  2. 01.02

    Featured is a toggle

    The dish a kitchen wants seen first is a switch on the item, not a hand-built home page.

  3. 01.03

    The cart counts as you go

    Items added anywhere on the site raise the count in place, with no page reload.

Act 02/ 04Web2 captures

The order

Checkout without an app, then something to watch.

Most food orders die at the checkout, so this one asks for as little as it can get away with and remembers what it was told last time — a saved address is a tap rather than a form. Once the order is placed it gets a page of its own, because an order a customer can watch is an order they do not ring up about. And the words on that page are the words the kitchen sets, so there is never a second vocabulary between the two of them.

The cart with two items, each carrying its unit price, a quantity stepper and a remove link.
Two items, two steppers, one running total — and no account asked for yet.
A placed order shown with its reference, a pending status chip, the time it was placed, its channel and its two lines against the total.
The order after it is placed: a reference, a state, and the two lines behind the total.
  1. 02.01

    One toggle, not two flows

    Delivery or pickup changes the whole order, and the address block follows it rather than sitting beside it.

  2. 02.02

    Paid on the same screen

    Cash on delivery or online is chosen where the address is, not behind another step.

  3. 02.03

    One vocabulary, both ends

    Pending, confirmed, preparing, ready, out for delivery — the customer reads what the kitchen set, and cancel sits on the order itself.

Act 03/ 04Web2 captures

The console

A menu the owner controls.

The console exists so nobody has to ring a developer to change a price, publish an offer or rewrite the home page. That is a low bar and most restaurant systems still miss half of it: the menu is editable but the website is not, or the website is editable but the offer codes live in a config file. Here the site itself is content — hero, banners, gallery, FAQs and contact pages — and the dashboard answers the two questions an owner actually asks mid-service: what is coming in, and where from.

The menu management table listing dishes with their category, veg or non-veg type, price, minimum order, pre-order time, availability toggle and featured star.
One row per dish, and the two switches that matter — available, and featured.
The console dashboard with customers, orders, revenue and menu items on one row, and new, in-kitchen, delivered and cancelled orders on the next.
Four states as four tiles, not one list — and an accepting-orders switch over them.
  1. 03.01

    Priced and published here

    Categories, items, photographs, prices and offer codes, all in the one console.

  2. 03.02

    Availability is a switch

    Sold out is a toggle per dish, so a mid-service change costs nobody a menu rebuild.

  3. 03.03

    Every channel counted apart

    Walk-in, dining, takeaway, online and the third-party aggregators each keep their own count rather than sharing one total.

Act 04/ 04Mobile2 captures

The floor

The same console, in a pocket.

A busy floor does not walk back to a desk. What it gets is not a companion app carrying a subset of the truth: it is the same console reached from a pocket, so a dish switched off between tables is switched off on the site before the next customer loads the menu. One system with two ways in, rather than two systems and a nightly job to keep them agreeing. It ships as a signed Android build; the iOS target sits in the codebase and has not been submitted.

The Android panel home screen with an accepting-orders switch, the day’s revenue, and tiles for orders, menu items, active offers and delivered orders.
Open or closed is the first control on the screen, above the day’s takings.
The Android menu list, each dish carrying its category, its price and an availability toggle.
The same dishes, the same toggles — because it is the same record.
  1. 04.01

    Open, or closed

    Accepting orders is a switch on the first screen, not a setting three taps in.

  2. 04.02

    One record, two clients

    The phone and the site read the same row, so there is no window in which the two of them disagree.

  3. 04.03

    Over the console’s own API

    Flutter, Riverpod and Dio against the endpoints the panel already calls — no second backend.

The last word

This shows how Famysys builds when a kitchen sells in more than one place at once: one order record, and three surfaces that read and write it — a browser the customer needs nothing to use, a console the owner runs the business from, and a phone the floor carries. We start from your menu and your order flow rather than from a template.

Built in

  • Storefront
  • Menu & categories
  • Cart & checkout
  • Delivery or pickup
  • Order tracking
  • Admin console
  • Offers & codes
  • Site content
  • Channel counts
  • Android app
  • One API

All projects

Let's build what's next

Technology alone doesn't transform businesses.The right partnership does.

Modernizing systems, building a new product, or exploring AI-driven transformation — Famysys helps you move forward with confidence.

Schedule Executive SessionEmail Us Directly
  • SOC2 Type II Compliant
  • Strict Commercial NDA
  • Zero Lock-In Guarantee

Famysys

We Engineer Clarity

Scan to Connect

Instant digital business card & WhatsApp link