Turns a meal-planner shopping list into a reviewable cart proposal — and stops there, deliberately
Overview
My self-hosted meal planner knows what I need to buy. My grocer's site knows what things cost, which promotions apply, and what is on clearance. Reconciling those by hand every week is exactly the kind of small recurring chore that automation should absorb.
Designed and built it, including the boundaries — which are most of the design.
Shopping-list needs are normalized, matched deterministically against the catalogue, and evaluated against active promotions to produce a cart proposal a human reviews. Local preference recording means a correction I make once is remembered. It exposes its capabilities over Model Context Protocol so an assistant can call it.
Dry-run is the default. Cart mutation exists but is disabled behind an explicit apply flag. The out-of-scope list is written into the project and is not a TODO: no checkout, no payment, no delivery scheduling, no order submission, no loyalty-balance spending, no autonomous purchasing, and no attempt to work around bot protection.
Working end to end at v0.1.0, in weekly use, with a fixtures-first test suite so promotion logic can be verified without hitting a live site.
Nothing structural — this is the project where I got the boundary right on the first try, and the reason is that I wrote the out-of-scope list before the feature list. Automation that touches money should propose, not act. The review step costs me thirty seconds a week and removes an entire category of failure I would otherwise have to engineer against.
Lessons
Writing the out-of-scope list before the feature list produced a better design than any amount of later refactoring would have. When automation touches money, the review step is the product.
Stack
Talk shop
If you're hiring for similar backend, AWS, voice, or integration work — or just want to compare notes on architecture — reach out directly.