One app for a daily milk delivery business

• ProductDairy subscription and delivery platform
• PlatformFlutter, one codebase for Android and iOS
• UsersCustomers, delivery partners, vendors, administrators
• SizeAbout 7,500 lines of Dart in the app, plus 38 automated tests
• StatusRuns on Android with sample data; not launched, so no customer or revenue results yet

The problem

Milk repeats every day, and every household's schedule is different, so a normal shopping app can't run this business.

One family wants a litre of cow milk each morning, buffalo milk each evening and curd on alternate days. They travel, skip a Sunday, or double an order for guests. Each change has to reach the right vendor and delivery partner before a nightly cutoff.

The business needs those small decisions turned into exact daily quantities, routes and charges, with no double orders and no missed changes.

The solution

One app gives each role the tools for its own job, and all four work from the same schedule.

• CustomerShop and cart, flexible subscriptions, pause and vacation mode, delivery calendar, prepaid wallet or monthly billing, offers, complaints.
• Delivery partnerRoute in stop order, consolidated load sheet, customer instructions, code check at the door, missed-delivery reporting, history.
• VendorTomorrow's requirement, stock shortages, inventory, procurement, suppliers, pricing, cutoffs, holidays, complaint refunds.
• AdministratorMonthly recurring revenue, active and paused subscriptions, milk volume, churn, failed payments, partner performance, vendor approvals.

How a day moves

• Step 1Each subscription follows its own rule: daily, alternate days, chosen weekdays or every few days.
• Step 2Customers can change any day until the vendor's cutoff, such as 10 PM for Harsha Farms.
• Step 3At the cutoff, the engine applies quantity changes, skips, pauses and holidays, then creates the day's orders.
• Step 4Prepaid wallets are charged. If stock or money runs short, the order is held and released automatically once that is fixed.
• Step 5Orders flow into each partner's route and load sheet. One code per household confirms the whole drop at the door.
• Step 6Delivered orders close into monthly invoices, and missed prepaid deliveries are refunded to the wallet.

Inside the app

Screens for all four roles, shown with sample data.

Key decisions

Four decisions shaped the build, and each one traded a little flexibility for fewer ways to go wrong.

• Flutter instead of SwiftOne codebase for Android and iOS. The first version was a Swift build, which was retired. iOS builds still need Xcode or a cloud Mac.
• One order per subscription per dayAn order's ID is its subscription and day, and each subscription records how far it has been generated. The automation can run any number of times without creating or charging an order twice.
• Cutoffs follow the city's time zoneA phone's clock should not decide when a day locks. Tests confirm the cutoff follows the city, not the device.
• Cart built on the same engineCheckout creates one-time subscriptions with a locked price, charged the evening before. Charging, orders and refunds need no second code path.

Design

The brand is designed to feel like a premium Indian dairy, not a generic delivery app.

• IdentityDeep forest green, warm milk white and soft gold, with Fraunces for headings and DM Sans for information.
• Design systemShared colour, type, spacing and motion tokens plus reusable components keep all four roles feeling like one product.
• Built for the jobCustomer screens are photo-led, while partner screens use large targets and big text for use outdoors.
• MotionA milk bottle fills when an order is placed, the product flies into the cart, and a gold burst marks a finished route.

Testing

The project has 38 automated tests, and 37 passed on the latest run on 31 October 2026.

The one failure is a calendar test that taps tomorrow on the current month's grid. On the last day of a month, tomorrow is on the next page, so the test can't find it. The problem is in the test's date assumption, not in the delivery logic.

Four engine tests cover the rules that cost money when they break, including generation, cutoffs, wallet charges, refunds and billing. Interface tests drive sign-up, subscribing, checkout and the code check at delivery, then check each role's main screens at four screen sizes and with large system text.

Status and next steps

Harsha Farms works end to end on one device, but it needs a backend before real customers can use it.

Data is stored on the device as JSON, and sign-in uses demo accounts. Payments always approve through a simulated gateway, and the scheduler runs inside the app. Push notifications and QR scanning are not built.

• Step 1Connect a cloud backend for real accounts, shared data and a server-side scheduler.
• Step 2Add phone sign-in and live payments through a gateway such as Razorpay.
• Step 3Complete the iOS build.