Tiffin Subscription and Route-Delivery App for a Hyderabad Tiffin Centre (Flutter)

RuchiBox is a mobile application plus a small REST backend that runs the daily routine of a home-style tiffin centre in Hyderabad — the kind that delivers warm lunches in steel carriers to offices, coaching centres and PG hostels across two or three localities. The centre's business lives and dies on details a paper notebook cannot hold: who paused from tomorrow, who is on leave next week, which delivery boy carries which route, which steel carriers did not come back, and what every household actually paid for last month.

The app serves three roles. Customers subscribe to a meal plan (veg day pattern, monthly rate), pause or resume with a 9 PM cut-off rule, see the weekly menu, rate dishes and pay by cash or UPI reference. Delivery partners get today's ordered stop list per route, mark each delivery Delivered or Not Delivered with a reason (absent, holiday, refused), and log carrier hand-backs — the screen caches locally, so a basement lift with no signal does not stop the round. The owner manages menus, rates, routes and subscriptions, and generates month-end bills that charge only the meals actually delivered, with a dues list and a missing-carrier report.

It is built with Flutter/Dart on the front end (the framework named in JNTUH R22's mobile-application elective) and a Node.js/Express + MongoDB backend from the Full Stack Development course, with JWT role-based access throughout — a realistic, demo-ready project for the JNTUH MCA R22 project-work viva.

A Hyderabad tiffin centre delivering 150–200 subscription meals a day runs its entire operation on a paper notebook: who is active, who paused, who skipped for a festival, which route and delivery boy covers which street, how many steel carriers are outside, and what each household owes at month end. Pauses arrive as WhatsApp messages at midnight and get missed; delivery lists are rewritten by hand each morning and last-minute changes slip through; bills are hand-tallied from tick marks and argued over; carriers silently disappear. There is a need for a mobile system with a small backend that manages subscriptions with a consistent, code-enforced cut-off rule, generates the day's route-wise delivery list automatically, records delivery outcomes with reasons, bills only meals actually delivered, tracks carrier circulation, and gives the owner a truthful month-end picture — without collecting Aadhaar or any government identity number, and without per-order marketplace commissions.

Abstract

This project builds a subscription-and-delivery system for a Hyderabad tiffin centre: a Flutter app for customers, delivery partners and the owner, backed by a Node.js/Express + MongoDB API. The core is the daily cycle: at the evening cut-off the system freezes tomorrow's delivery list per route from active, unpaused subscriptions; partners run their rounds and mark outcomes; month-end bills charge only delivered meals.

Introduction

Hyderabad's office-goers and students sustain a large industry of home-style tiffin centres on monthly subscription. Menus repeat weekly, subscribers pause constantly, carriers circulate in a loop that must come back, and payments settle at month end against hand-tallied counts. A centre serving 150–200 meals a day tracks all of this in a school notebook. One missed pause becomes a refund argument; one forgotten stop, a hungry customer.

Existing System and Its Limitations

• Subscriptions and pauses are remembered in a notebook and WhatsApp messages — nothing is dated, so disputes are common.
• Delivery lists are rewritten by hand each morning; last-minute pauses are missed.
• Meal counts for billing are tallied from ticks; errors irritate everyone.
• Steel carriers circulate untracked; replacements are bought until someone counts.
• Gap: food-delivery platforms are per-order marketplaces, not subscription managers, and their commissions do not suit ₹60-a-meal economics; nothing affordable exists for a centre's own round.

Proposed System

• Subscriptions with a lifecycle: Active → Paused (date range) → Resumed → Cancelled, with a 9 PM cut-off — a pause requested after cut-off takes effect the day after next, and that rule is applied consistently by code, not by mood.
• A daily generation job at cut-off builds tomorrow's delivery records per route from active subscriptions and the weekly menu.
• Route-wise rounds: the delivery partner's screen shows ordered stops with pending/delivered counts, marks Delivered or Not Delivered with a reason, and caches in sqflite with a retry queue for dead zones.
• Billing only for delivered meals: each DailyDelivery record carries status and reason; the month-end job bills delivered meals at rates from a configurable rate table, records cash/UPI-reference payments and produces a dues list.
• Carrier ledger: carriers out at delivery and back at hand-over; a missing-carrier report per route.
• Menu and feedback: an editable 7-day menu cycle with per-dish ratings so the owner can retire what nobody eats.

Feasibility Study

• Technical: Flutter gives one Dart codebase for all three roles; Express + MongoDB matches the Full Stack Development course; the generation job is an idempotent endpoint and sqflite covers the only offline screen. Everything is free and runs on a laptop for the demo.
• Economic: No licence or per-order commission; the backend runs on the centre's existing PC and the app on phones the owner and partners already own.
• Operational: The app mirrors the notebook screen for screen; the owner needs one training hour, and customers are enrolled by the desk with a phone number.

In scope

• One tiffin centre, three localities split into routes, up to ~250 active subscriptions, one lunch service per day.
• Three roles in one Flutter app: customer, delivery partner, owner; Express + MongoDB backend.
• Subscription lifecycle with pause windows and cut-off; weekly menu cycle; daily delivery generation and outcome capture.
• Month-end billing with rate table, payments ledger, dues list; carrier in/out ledger; dish feedback aggregation; CSV exports.

Out of scope (v1)

• Online payment gateway (UPI is recorded as a reference string, not processed).
• Live map tracking and route optimisation — routes are ordered stop lists, and Google Maps integration is future work.
• Push notifications and WhatsApp bots (reminders are shown in-app and exported).
• Breakfast/dinner services and multi-centre (franchise) deployment.

The project follows an incremental SDLC with fortnightly reviews, aligned to how the JNTUH R22 project work itself is reviewed: a thin vertical slice (subscribe → generate → deliver → bill one day) exists by week 5, and each increment widens it, which matches the university's review pattern of demoing working software each time.

Testing approach: unit tests for the cut-off logic, billing arithmetic and carrier counters; widget tests for the pause and delivery screens; Mocha/Chai API tests including the pause-after-cut-off case, double generation of the same day (idempotency) and role abuse; and a scripted dead-zone trial that runs a route in airplane mode and reconciles every status after the network returns.

The system is a mobile client with a stateless REST backend and one document database, with a small offline-cache layer only where the domain demands it (the delivery round).

1. Flutter client (three roles): Riverpod providers hold per-role state; the customer screens talk to subscription, menu and payment endpoints; the delivery screen loads the day's stops and writes outcomes to a local sqflite queue when the network is absent, flushing with retries when it returns.
2. Application tier (Node.js/Express): JWT verification and role middleware guard every route; controllers delegate to services holding the business rules — the cut-off generator, the billing calculator, the carrier ledger. The daily generation endpoint is idempotent per date: calling it twice yields one set of delivery records.
3. Data tier (MongoDB via Mongoose): collections for users, customers, subscriptions, pause windows, menu days, daily deliveries, payments, routes and feedback. Mongoose schema validation guards writes; the billing job reads only delivery records whose status is Delivered.

flowchart LR
  C["Customer phone"] -->|"HTTPS + JWT"| API["Express REST API"]
  D["Delivery partner phone"] --> APP["Flutter app (Riverpod)"]
  APP --> CACHE[("sqflite cache + retry queue")]
  CACHE -->|"sync when online"| API
  O["Owner console screens"] --> API
  API --> MW["JWT verify + role middleware"]
  MW --> S["Services: cut-off generator, billing, carriers"]
  S --> DB[("MongoDB via Mongoose")]
  S --> B["Month-end bill + dues CSV"]

Data model

erDiagram
  USER ||--o{ SUBSCRIPTION : owns
  ROUTE ||--o{ CUSTOMER : covers
  CUSTOMER ||--o{ SUBSCRIPTION : holds
  SUBSCRIPTION ||--o{ PAUSE_WINDOW : "is paused by"
  SUBSCRIPTION ||--o{ DAILY_DELIVERY : "receives"
  ROUTE ||--o{ DAILY_DELIVERY : "groups per day"
  USER ||--o{ PAYMENT : records
  SUBSCRIPTION ||--o{ PAYMENT : "is settled by"
  MENUDAY ||--o{ DAILY_DELIVERY : "cooks for"
  SUBSCRIPTION ||--o{ FEEDBACK : rates

  USER {
    string id PK
    string name
    string role
    string mobile
    string passwordHash
  }
  ROUTE {
    string id PK
    string name
    string stopOrder
    string partnerId FK
  }
  CUSTOMER {
    string id PK
    string name
    string mobile
    string address
    string routeId FK
    string preferences
  }
  SUBSCRIPTION {
    string id PK
    string customerId FK
    string vegPattern
    string status
    date startedOn
    decimal monthlyRate
  }
  PAUSE_WINDOW {
    string id PK
    string subscriptionId FK
    date fromDate
    date toDate
    datetime requestedAt
  }
  DAILY_DELIVERY {
    string id PK
    string subscriptionId FK
    date deliveryDate
    string status
    string reason
    int carrierOut
    int carrierBack
  }
  MENUDAY {
    string id PK
    int dayOfWeek
    string items
  }
  PAYMENT {
    string id PK
    string subscriptionId FK
    string month
    decimal amount
    string mode
    string reference
  }
  FEEDBACK {
    string id PK
    string subscriptionId FK
    date forDate
    int rating
  }

Delivery-outcome states

flowchart LR
  P["Planned"] --> OFD["Out for delivery"]
  OFD --> DL["Delivered"]
  OFD --> ND["Not delivered: absent / holiday / refused"]
  ND -->|"next day retry"| P

Customer records carry only name, address, mobile and meal preferences — no identity documents — so the centre holds nothing it cannot justify.

• Online payments (UPI intent/Razorpay) with automatic bill reconciliation and payment reminders.
• Google Maps route view with optimised stop order and live partner location for the owner.
• Push notifications for menu changes, pause confirmations and bill availability.
• Breakfast and dinner services with per-slot subscription plans and a shared generation job.
• Demand analytics — pause-density forecasting for purchasing, and per-locality growth trends for planning a new route.