Subscription deliveries that schedule, route and bill themselves

Recurring delivery looks simple until you write down the rules. A customer takes two litres daily, another takes three on alternate days, a third pauses for a fortnight and expects the bill to reflect it.

Someone has to decide, every morning, exactly what leaves the building and on which route, and then reconcile what actually got delivered against what gets charged. Done by hand, that job scales badly and gets more expensive precisely when the business is growing.

• Modelled the subscription itself as the source of truth (quantity, frequency, and the specific weekdays it runs), so the daily delivery list is derived, never typed.
• Generated each day's deliveries with a scheduled job that runs before the day starts, so the operations team opens the morning with the run already built.
• Made the delivery record the billing record, so a missed drop reduces the bill without anyone remembering to adjust it.
• Built the customer portal and the operations portal from one codebase, so a change to how a plan works cannot mean two different answers in two different places.
• Kept every balance derived from movements rather than stored as a number, so a disputed bill can be walked back through the exact deliveries behind it.

Outcome. Daily delivery runs are generated automatically from active plans, with no manual list-building. Missed and completed deliveries feed billing directly, so what is charged matches what was delivered. Customer and operations experiences ship from a single codebase and a single set of rules.