More project photos (2)
The problem
In most Indian households, the daily milk supply runs on an informal arrangement with the local doodhwala: quantities are agreed verbally, vacations are communicated by a phone call or a note on the door, and the monthly bill is a handwritten figure that neither side can fully reconstruct. Missed deliveries during vacations lead to milk left at the doorstep or charged-but-undelivered days, and billing disputes are common because there is no shared record. This project replaces that fragile arrangement with a two-sided Android app. Customers manage their own subscription — milk type (cow, buffalo, A2), daily quantity, delivery-day rules and vacation pauses — while the vendor gets a clean daily route list and the billing math is done automatically from the delivery log. It is a realistic, well-scoped mobile product: Firebase for auth and data, Flutter for a single cross-device codebase, and a billing engine with genuinely correct edge cases (partial months, paused days, per-day quantity changes).
Signs up with phone-OTP, builds the milk subscription, schedules vacation pauses and reviews the calendar and invoices.
Follow the working sequence
How it works
- The customer signs up with phone-OTP (Firebase Authentication) and creates a household profile with their delivery address.
- They build a subscription: milk type, daily quantity and cadence. The app shows a daily and monthly cost estimate from the vendor's rate card.
- Each morning the vendor's route screen lists only the active stops with quantities; the rider marks deliveries as they happen, which writes to the shared delivery log.
- Before a vacation, the customer schedules a pause range in the calendar. The billing engine excludes those days and the route list drops the stop automatically.
- On the 1st of the month, the app generates the invoice from the delivery log: quantities × rate, minus paused days, with payment status tracked against UPI payments.
- Both sides see the same history — calendar, log and invoices — so a billing question is settled by opening the app, not by memory.
Tech stack:
- Flutter · Dart (single codebase)
- Firebase Authentication (phone OTP)
- Cloud Firestore (subscriptions, logs, invoices)
- Firebase Cloud Messaging
- Razorpay · UPI intent (payments)
- fl_chart (billing analytics)
- Git
| Parameter | Value |
|---|---|
| Platform | Android 8.0 (API 26) and above (design target) |
| Codebase | Single Flutter codebase for customer + vendor roles (implemented) |
| Backend | Firebase (Auth, Firestore, Cloud Messaging) — no self-hosted server |
| Quantity step | 0.5 litre increments (implemented) |
| Pause cutoff | 8:00 PM previous evening (configurable constant) |
| Billing cycle | Monthly, auto-generated on the 1st (design target) |
| Demo rates | Cow ₹62/L, buffalo ₹70/L, A2 ₹95/L — indicative example rates, vendor-configurable |
| Offline support | Read-only cached views; writes require connectivity (expected) |
| Demo dataset | 1 household, 3 months of realistic sample deliveries and invoices |
Project features
- [Subscription plan builder] Choose cow (₹62/L), buffalo (₹70/L) or A2 (₹95/L) milk, set daily quantities in 0.5 L steps, and pick a cadence — daily, alternate days or weekdays only. Rates are indicative and vendor-configurable.
- [Vacation pause scheduler] Select a from–to date range; every paused day shows on the calendar with zero delivery and zero charge. Pauses lock at 8 PM the previous evening so the vendor's route is final.
- [Delivery calendar] A month view marking each day as delivered, paused or upcoming, with quantities per day — the single shared record both sides can point to.
- [Auto monthly billing & payment tracking] The bill is generated from the delivery log, not typed by hand: line items per milk type, pause-day deductions, free delivery, and a running amount due. Bills generate on the 1st of each month, and each invoice tracks UPI payment status — paid, due or overdue — with a per-month history the customer can audit.
- [Delivery log] Every delivery is timestamped with quantity, time and acceptance mode (accepted by customer or gate drop), giving a tamper-evident history for disputes.
- [Vendor / rider view] The vendor sees the day's route with paused households automatically skipped, plus per-stop quantities — designed so no milk is wasted on empty houses.
- [Notifications (optional)] Morning delivery alerts and pause confirmations via Firebase Cloud Messaging — implemented as a configurable module, documented as optional in the report.
- [Multi-vendor marketplace (future scope)] Comparing vendors by rate in one app is designed but not implemented; the report lists it explicitly as future scope.
What is included
- Complete Flutter app source (customer + vendor/rider views)
- Firebase project configuration guide (Auth, Firestore rules, FCM setup)
- Billing engine with pause-day and partial-month logic, unit-tested
- Sample dataset: 3 months of realistic deliveries, pauses and invoices
- Project report PDF (problem analysis, architecture, data model, billing logic, testing)
- PPT presentation for final review
- Viva Q&A preparation document (Flutter, Firebase, billing edge cases, app distribution)
Limitations & prerequisites
- Built for a single vendor per deployment — the multi-vendor marketplace is future scope, not implemented.
- Payments use UPI intents/test mode in the demo build; a production Razorpay key and KYC are the buyer's responsibility.
- The app needs internet for writes; offline mode is read-only cache, not full sync.
- Pause cutoff (8 PM) is a fixed app constant in the demo; making it vendor-configurable is listed as an enhancement.
- Demo rates are indicative examples, not a pricing claim about any real dairy.
Frequently Asked Questions
How does the vacation pause actually work?
The customer picks a from–to date range in the delivery calendar. The billing engine bills ₹0 for every paused day, and the vendor's route screen automatically skips that household on those dates, so no milk is wasted and no charge appears on the bill.
Who are the two roles in the app?
Customers manage subscriptions, pauses and payments; the vendor (or rider) sees the daily route list with quantities and marks deliveries. Both sides read the same delivery log and invoices, which is what settles billing disputes.
How is the monthly bill calculated?
From the delivery log, not by hand: each delivered day's quantity × the milk rate, summed per milk type, minus paused days, with delivery charges shown as free. The invoice generates automatically on the 1st of the month.
What happens if the customer forgets to schedule a pause?
Deliveries continue as scheduled and are billed normally — the app cannot know about an unrecorded vacation. The report documents the 8 PM cutoff rule and this behaviour as an accepted design decision.
Does it handle real payments?
The demo build uses UPI intents and test-mode flows. Wiring a production Razorpay account with KYC is a deployment step for the buyer, documented in the setup guide.
Is this project suitable for a final-year project?
Yes — for Computer Science, IT and mobile-application programs. It demonstrates Flutter development, Firebase backend design, a real billing engine with edge cases, and a genuinely usable two-sided product.
Components & software requirements
- Flutter · Dart (single codebase)
- Firebase Authentication (phone OTP)
- Cloud Firestore (subscriptions, logs, invoices)
- Firebase Cloud Messaging
- Razorpay · UPI intent (payments)
- fl_chart (billing analytics)
- Git
Delivery information
Built-to-order project. Delivery timeline is shared after order confirmation based on current queue.
Support terms
Complete documentation, setup guide, and viva preparation included. Support for setup and explanation provided.
Download free synopsis (PDF)
Enter your name and email — the synopsis PDF downloads immediately. We may send occasional project updates; no spam, unsubscribe anytime.