CLIENT DELIVERY · RESTAURANT / HOSPITALITY

Restaurant Ordering & Management Platform — CMS, Mobile App & API

A custom restaurant technology platform connecting menus, events, online ordering, payments, customer engagement and mobile experiences through a centralized CMS and API.

Built as a hospitality mobile platform and designed to evolve into a direct-to-customer restaurant ordering and engagement system. CodeIgniter + Android API. Client name omitted where needed.

CodeIgniter 3REST APIAndroid StudioFCMSagePayAdminLTE
Build a Restaurant Platform Watch demos AI Voice path
Industry
Farm shop · cookery school · hospitality / restaurant
Type
Restaurant CMS + REST API + mobile
Roles
Admin CMS · mobile app users (API)
Stack
CodeIgniter 3 · MySQL · Android Studio · FCM · SagePay
Proof
5 screens · 0:55 + 1:29 demos
RESTAURANT · CMS · MOBILE · API

CMS → API → mobile → payments → engagement → AI channels.

Who this is for. Restaurants, farm shops, hospitality venues and founders building first-party ordering and engagement—not a brochure WordPress theme.

What you get. Evidence of CodeIgniter AdminLTE CMS + JSON REST API + FCM + SagePay vouchers consumed by a native Android app, with working demos. Hospitality mobile CMS is the proof; direct restaurant ordering + CRM + AI is the commercial story.

Searches this page answers: restaurant ordering software · restaurant management software development · restaurant mobile app · headless restaurant CMS · direct online ordering · AI voice ordering · custom restaurant software

Who this platform is for

Independent restaurants & farm shops

Menus, events, vouchers and push without rebuilds for every copy change.

Direct-ordering operators

Own the repeat customer while still using marketplaces for discovery.

Multi-outlet groups (future)

Central menus/promos with outlet-level ops on one API.

Teams adding AI Voice later

API-first menu/order boundary ready for voice, WhatsApp and web agents.

The restaurant digital problem

A long-running farm shop and cookery school needed mobile content—events, menus, vouchers and push—updated without shipping a new app build for every copy change. WordPress or a static site would not feed a native Android product with FCM and SagePay checkout.

The broader market problem is the same: marketplaces for discovery vs owned channels for relationship and repeat orders.

Constraints

Delivery stayed inside the client’s stack. Native Android app built in Android Studio by the client team against this API. Full cart/POS/QR/CRM loyalty and AI Voice below are labeled future extensions, not claimed as shipped features of this build.

Marketplace discovery vs direct ordering

Third-party ordering apps help with reach and convenience. Industry discussions often cite marketplace commissions commonly in a broad 15–30% range—contracts vary by market and plan, so this page does not promise a fixed savings percentage. The safer commercial goal: reduce dependence on per-order marketplace commissions by moving repeat customers to owned channels.

RESTAURANT
    │
    ├── Third-party apps → Discovery / new customers
    └── Own channels → Relationship / repeat customers
              │
         Website · Mobile app · WhatsApp · QR · Voice

Hybrid growth model — don't abandon marketplaces

Use aggregators for acquisition. Use your own platform for retention and higher-control direct orders. That is more credible than “eliminate marketplaces.”

Aggregators / marketing → First purchase → Customer relationship
  → App / Website / WhatsApp → Repeat orders → CRM / loyalty

Your venue can own: customer profiles, order/voucher history, preferences, direct communication and campaign data—while still using marketplaces where they help discovery.

What was delivered

Internal AdminLTE CMS for marketing staff, JSON REST API for the Android app, voucher commerce with SagePay, and FCM campaigns—one MySQL database as source of truth. Admin login, dashboard, events, menu items, vouchers, push and newsletter modules plus REST endpoints documented for the Android Studio client.

Centralized restaurant operations CMS

Not “brochure content only”—an operational desk: menus, categories, dishes, prices, events, promotions, vouchers, offers, push and newsletter tiles colour-coded for non-developers.

RESTAURANT CMS → Menu · Events · Content / offers
        │
        ▼
       API → Website · Mobile app · Partner channels
Restaurant CMS admin login with venue logo and email password form
AdminLTE dashboard with CMS events menu vouchers and notification tiles

Colour-coded tiles: users, CMS pages, cookery school, farm shop, events, vouchers, menu, offers, push and newsletter.

Menu items list with categories prices and veg non-veg type

Restaurant-style menu grid: category, price, veg/non-veg type and publish status for the app.

Events management list with categories start dates and active status

Event categories, start/end times and active flags—surfaced to mobile via the sync API.

Vouchers list with cookery and farm shop categories and prices

Cookery-school and farm-shop vouchers with SagePay checkout on mobile and payment history in admin.

API-first / headless restaurant CMS

Content is maintained centrally while apps and other customer interfaces consume the same API. The mobile application is not the product—the API is the platform boundary.

Restaurant Domain API
      │
 Mobile · Website · AI Agent (future)
      │
 Business rules → Database

One backend, multiple customer experiences

CMS → API → Mobile App · Website · QR menu (future)
                 │
          Customer journey

Future channels on the same API: WhatsApp, AI Voice, kiosk. Shipped channel today: native Android + admin desk.

Working-system videos

Native Android app

Watch on YouTube → · 0:55 · Mobile app watch page →

Admin CMS & API

Watch on YouTube → · 1:29 · CMS watch page →

Original architecture

Android app → CodeIgniter Api controller → MySQL
Admin CMS ──────────────────────────────┘
Api → FCM push
Api → SagePay (vouchers)

Restaurant events & experience management

Special dinners, cookery classes, farm-shop promotions and seasonal offers already live in the CMS and sync to mobile. Future: registration, ticketing, attendance and CRM follow-up on the same event objects.

Own your restaurant ordering channel — future depth

Shipped commerce seed: vouchers + SagePay with admin payment history. Natural extension: full menu cart, delivery/pickup, table QR, status tracking—still on one Order API.

Menu → Cart → Payment → Order API → Kitchen / POS (future)

Restaurant CRM & loyalty — future extension

Not claimed as a full CRM product in the original build. Direction: profiles with order/voucher history, preferences, visit frequency, segments and loyalty (points, coupons, reorder rewards)—then marketing automation.

Customer → Orders · Preferences · Feedback · Loyalty
        → CRM → Segmentation → Marketing automation

Post-order automation sketch: thank-you → loyalty points → review request → reorder reminder → personalized offer (via AI Automation / n8n-style workflows calling the Restaurant API).

POS, KOT & QR ordering — future extension

Not claimed as shipped. One order, one source of truth: channels → Order API → POS → kitchen / inventory / finance. India-relevant KOT status (preparing → ready → pickup/delivery) and table QR → digital menu → UPI/card → kitchen.

Table QR → Digital menu → Cart → Pay → KOT → Kitchen → Ready

AI restaurant layer — future architecture

Not claimed as shipped in this project. Same Restaurant API can power multimodal agents:

  • AI Voice ordering — phone → STT → menu/order understanding → cart → pay → confirmation
  • WhatsApp / web chat — reorder, hours, status, offers
  • Menu assistant — dietary preference & spice level using verified ingredient/allergen data (never invent safety facts)
  • Ops summaries — assistive analytics for managers; humans retain control
Voice · WhatsApp · Web/App → AI Gateway → Restaurant API
        → Menu · CRM · Orders → POS / Kitchen (future)

Links AI Voice, AI Automation and AI & Data.

Analytics & demand forecasting — future

Direct vs marketplace mix, AOV, repeat rate, top dishes, peak hours, event performance—then optional demand models (history + daypart + events + promos) for staffing/inventory assist. Managers keep final control; no overclaimed ML accuracy.

Multi-location & multi-tenant SaaS — future

SaaS Platform → Restaurant A · B · C
     each: Menu · CRM · Orders · Customers (isolated)
Restaurant Group → Outlet A · B · C (menus, staff, orders)

Tenant isolation, RBAC, plans, feature flags and API quotas turn the CMS→API pattern into restaurant SaaS. See SaaS development.

Modern architecture path

Web / Mobile / QR / Voice → API Gateway
  → Menu · Order · CRM services → PostgreSQL
  → Redis / Queue → POS · Payments · AI

Typical rebuild: Next.js/React · NestJS or FastAPI · PostgreSQL · Redis · React Native · Razorpay/Stripe · WhatsApp · OpenAI/Claude/Gemini as tools behind APIs. Historical evidence remains CodeIgniter 3 + MySQL + AdminLTE + Android Studio client.

Security notes

  • API authentication and HTTPS for mobile clients (production consideration in this build)
  • Admin session hardening for non-technical staff desks
  • Future: RBAC, audit logs, rate limits, webhook verification, payment tokenization
  • Do not claim PCI compliance unless a specific deployment is assessed—payment providers handle card data where used

My role

  • Full-stack delivery — CodeIgniter CMS modules, REST API, SagePay hooks, FCM campaign wiring
  • Ops UX — AdminLTE desk for marketing staff (events, menus, vouchers, push)
  • Mobile integration — API contract for Android Studio client (app built by client team)
  • Evidence — demo capture of CMS and running Android product
Restaurant CMSREST APIMenu / eventsVouchers / SagePayFCM pushAdminLTEAndroid API contractHospitality ops

Technology stack

CodeIgniter 3MySQLAdminLTEREST APIAndroid StudioFCMSagePay

Outcomes

  • Marketing staff update events, menus and vouchers without developer deploys
  • Native Android app consumes one REST API with FCM and SagePay
  • Dual demos: 0:55 mobile and 1:29 CMS on this site
  • Clear path from hospitality CMS proof → direct ordering, CRM, POS/QR and AI Voice—without overclaiming
FAQ

Restaurant ordering & management questions

CMS, API, mobile and direct ordering—hospitality-booking FAQ leftovers removed.

Restaurant ordering software lets customers browse menus, place orders and pay through owned channels (app, website, QR, voice), while staff manage menus, events, promotions and operations from a CMS—with an API as the shared boundary.

Yes. A first-party platform gives a branded experience, direct payment and customer history. This case study proves CMS + REST API + native Android consumption; full cart/KOT flows are a natural modernization path.

Marketplaces help with discovery; owned channels help with repeat orders, customer relationship and margin control. Prefer a hybrid strategy—not “abandon aggregators.”

As a future extension: Order API → POS → kitchen/inventory/finance so one order is one source of truth. Not claimed as shipped in the original CMS delivery.

Yes architecturally. The delivered native Android client consumed the REST API for menus, events, vouchers, FCM and SagePay checkout. Broader menu-order carts can reuse the same API boundary.

Yes. AdminLTE modules for menu items (category, price, veg/non-veg, publish), events, vouchers, offers and push—updated without shipping a new app build for every copy change.

As a future extension: table QR → digital menu → cart → pay → KOT. Not claimed as shipped here.

As a future channel on the same Restaurant API (reorder, status, offers)—via automation/AI gateway. Not claimed as shipped in the original build.

As a future extension: phone → STT → intent → Menu/Order API → payment → confirmation, with human escalation. Allergen answers must use verified restaurant data—not LLM invention. Not claimed as shipped.

Original delivery was a single hospitality venue CMS. Multi-location / multi-tenant SaaS (outlet menus, staff, orders, analytics) is documented as an architecture extension.

As a future layer on CRM: points, coupons, reorder rewards, segments and campaigns—fed by order history. Original build includes vouchers and FCM campaigns as engagement seeds.

Events (categories, dates, active flags) sync to mobile via the API today. Ticketing/reservation depth can expand; CRM follow-up is a labeled extension.

Yes—the CMS→API→channels pattern is a strong multi-tenant foundation (tenant isolation, RBAC, plans). See SaaS development for productization.

As a future path: post-order thank-you, review request, reorder reminder and personalized offers via automation tools calling the same APIs—with humans owning sensitive decisions.

Channels (app/web/QR/voice), menu complexity, payments, whether POS/KOT is required, single vs multi-outlet and whether AI Voice comes later. Screenshots beat a long RFP. Email hello@unifiedpbx.in.

Building restaurant ordering or a mobile CMS?

Share channels (app/web/QR/voice), menu modules, payments and whether POS or AI Voice comes later. The first reply maps CMS, API and customer-channel boundaries—not a generic WordPress theme.

Build a Restaurant Platform