Milk Tomorrow

The shopping list that writes itself—before the milk is gone.

Comment

Inspiration

Household shopping lists begin too late: after somebody notices an empty shelf. That causes two ordinary but persistent failures. Sometimes nobody buys the milk because everyone assumes another person will. Sometimes several people buy it because they notice independently.

Milk Tomorrow starts earlier. It is designed for busy families—including parents and children who should not need to understand inventory software—to answer three questions before breakfast:

  1. Are we likely to run short?
  2. How much should somebody buy?
  3. Who has the trip covered?

What it does

Milk Tomorrow models a household's consumption rhythm, forecasts a likely shortage before the milk is gone, recommends a practical quantity, and lets one family member claim the task for everyone.

The reset demo keeps the main decision calm and concrete: 89% chance of running short, pick up 2 bottles, I'll get it. Underneath that screen, it:

  • runs 1,000 possible consumption futures;
  • predicts crossing a one-breakfast, 340 ml safety reserve;
  • recommends whole 1 L packages from a 90th-percentile 48-hour supply plan;
  • explains the weekend effect with a weekday-only counterfactual;
  • coordinates one winning claim between tabs in a supported browser;
  • updates both tabs when the trip is claimed or completed;
  • adds the recorded purchase and reruns the forecast, moving the seeded near-term result to 0%;
  • treats “We still have some” as bounded feedback rather than a fabricated stock measurement; and
  • exposes the math, assumptions, activity, member switching, time travel, and reset in Tomorrow Lab.

How we built it

The forecast and coordination logic are pure TypeScript modules. For every future hour, the engine samples whether each fictional household member consumes milk, using weekday/weekend participation and hour-of-day weights, then samples a bounded serving amount. One thousand paths produce an empirical shortage probability, remaining-stock quantiles, median threshold-crossing time, and 90th-percentile purchase plan.

A second simulation replaces weekend probabilities with weekday probabilities. The difference explains the visible +7 percentage-point weekend effect in the reset scenario instead of attaching a vague “weekends are busier” label.

The interface uses React and Vite with a mobile-first responsive layout. Demo state uses localStorage, BroadcastChannel, storage events, and the Web Locks API. Web Locks serializes competing same-browser claim attempts in supported browsers; BroadcastChannel and storage events update other same-origin tabs. Eleven deterministic domain tests cover the forecast and coordination rules, with separate runtime-integrity, build, and static-hosting checks.

Challenges

  • Making a stochastic model reproducible for remote judging without hard-coding its output.
  • Defining shortage responsibly as a safety reserve instead of claiming knowledge of literal emptiness.
  • Turning a binary “still available” response into useful feedback without inventing precision.
  • Preventing near-simultaneous claims while keeping a zero-credential demo easy to open.
  • Preserving mathematical evidence in a screen simple enough for a non-technical family member.

What we learned

The hardest part of household forecasting is not adding more sensors. It is choosing honest abstractions. A safety reserve is more useful than a fake empty-time prediction. Coarse feedback can improve an estimate without becoming a false measurement. Coordination matters as much as prediction: even a correct alert fails if everybody—or nobody—acts on it.

What makes it innovative

Milk Tomorrow is not another shared shopping list. The list writes itself before the item is gone.

The project brings demand forecasting—usually associated with warehouses and supply chains—into one tiny, familiar household decision. Its technical depth is mostly invisible until a judge opens Tomorrow Lab. That contrast between a child-friendly surface and a serious, inspectable probabilistic engine is the core product idea.

Why it fits the Lifestyle Hacks Track

Milk Tomorrow addresses a small but repeating part of day-to-day life: noticing, planning, and coordinating a household purchase. It makes daily life easier by moving the shopping decision before the shortage and combining prediction, quantity, and responsibility in one flow. The project does not need to stretch into health, runtime AI, or large-scale social infrastructure to fit this track; its value is removing an everyday household friction before it becomes urgent.

Judging criteria alignment

Official criterion Evidence in the working prototype
Technical Execution Pure TypeScript forecast engine, 1,000 seeded paths, quantile-based planning, timezone logic, weekend counterfactual, tested coordination state machine, Web Locks, tab synchronization, and eleven deterministic domain tests.
Innovation & Creativity The list is created by forecasted need before a human notices the shortage; household-scale demand forecasting becomes a friendly family action.
User Interface and Design The main screen reduces the model to 89% → 2 bottles → I’ll get it, with responsive layouts, large actions, clear state changes, accessible controls, and progressive disclosure through Tomorrow Lab.

Technologies

  • React 19 and React DOM
  • TypeScript 7
  • Vite 8
  • Node's built-in test runner
  • Radix UI primitives and icons
  • Motion and @use-gesture/react through the mobile runtime
  • Fontsource Nunito and Roboto
  • Web Locks API
  • BroadcastChannel and storage events
  • localStorage for credential-free Demo Mode
  • Playwright tooling for mobile-runtime checks
  • OpenAI Codex and OpenAI image generation, disclosed below

Working demo and source

Reviewer test loop

  1. Reset and confirm 89% / 2 bottles / +7 pts.
  2. Open See the 1,000 simulated futures.
  3. Open a second tab and choose another household member in Tomorrow Lab.
  4. Claim the trip in one tab and watch both update.
  5. As the claimant, record Bought 2 bottles and confirm the near-term result moves to 0%.
  6. Reset, choose We still have some, then Move to tonight to see bounded feedback and re-evaluation.

Known limitations and responsible delivery

  • Forecasts are probabilities, not promises; “running short” means crossing a 340 ml safety reserve.
  • The demo uses a fixed clock and a fictional Sakura household with synthetic profiles.
  • Same-browser, same-origin synchronization is not cross-device household persistence.
  • Authentication, backend storage, scheduled forecasts, and notifications are roadmap items, not current capabilities.
  • The app estimates stock from starting state, purchase events, and coarse observations; it does not observe the refrigerator.
  • “We still have some” never becomes a made-up exact measurement.
  • Demo Mode collects no account, personal, precise-location, receipt, or credential data.
  • The current prototype does not use an LLM, external API, or external dataset at runtime.

AI, third-party, and generated-asset disclosure

  • The project owner originated and directed the concept, selected the visual direction, made product and technical-priority decisions, tested the experience, and owns the submission and presentation.
  • OpenAI Codex assisted with implementation, testing, browser verification, and documentation under human direction.
  • OpenAI image generation created design directions and the fictional milk, cloud, family, and submission artwork. No real person's likeness or personal data was used.
  • Third-party libraries, fonts, tooling, and the mobile runtime are listed in the public README and package manifest.
  • Credential-free Demo Mode uses no external API or dataset.

AI tools are disclosed as tools, not team members.

Built With

Share this project:

Updates

Submission history