Savor

Notability Pro to plan the flowchart of use cases for consumer base
Notability Pro to draw out possible display of various screens

Inspiration

Hundreds of thousands of Americans already sell food from home kitchens. Most of them do it on Instagram DMs and Venmo: no trust, no payments, no idea what is legal. Millions of households want fresh food made by a person nearby, and the only weekly option is still “go to the market on Saturday morning.”

We started from a bigger idea (a subscription box that runs itself) and shipped Savor: a local cottage-food marketplace for Michigan. Buyers build a box from real makers nearby and pick up at a public meetup. Makers list what they bake, see whether it is legal, and get a number for how much to make this week.

The existing products sit in three buckets:

Tools (Hotplate, Castiron): they help a seller take orders, but the seller still finds every customer alone. Castiron shut down in 2025 because a storefront without customers is just a bill.
Catalogs (Market Wagon): they bring shoppers, but you start from zero every week and vendors guess how much to bring. Guessing wastes food.
Chef meals (Shef): curated and weekly, but locked to chefs and to a handful of states where home-cooked meals are legal. Not bread, jam, or cottage sellers.

Savor is the fourth type: a short weekly menu of what is legal where you live, a box you can tap through in seconds, a forecast so makers are not guessing, and a chat path so Michigan’s “talk to the maker” rule is a product feature, not a PDF.

Michigan made online home-food sales much more workable in March 2026. We launched the prototype in Ann Arbor this weekend because the law finally matches the kitchen.

What it does

For the buyer. You open Savor, see makers near Ann Arbor, filter by distance and category, and add items to a box. You pick a public meetup (library, farmers market, campus) and a Saturday window. You can message a maker before cutoff. Michigan requires that contact path; everywhere else it is just why people buy from people.

For the maker. You list an item from a photo. Savor checks whether that food is allowed under cottage rules and whether the label story is complete enough to publish. Each week you see a capacity plan (“List 40”) instead of baking 50 and throwing away 12. After cutoff you see what actually sold. You drop at one pickup spot. You never have to find a customer on Instagram.

For anyone who would rather type. The Fetch.ai agent michigan-cottage-compliance (@michigan-cottage-com) lives on Agentverse and runs inside ASI:One with no custom frontend:

Can I sell pickles in Michigan? → no, with the botulism / commercial-kitchen reason
How much sourdough should I make? → List 40: …
nut-free breakfast box under $30 → packs a box under budget, picks a meetup, returns mock order IDs

The app is for browsing. The agent is for doing it in one sentence. They are two doors into the same marketplace.

What we learned

Cottage food is not “Shopify for cookies.” It is a constraint problem: allergens, weekly capacity, meetup logistics, and a statute that changes when you change the state.

If $p_i$ is the price of item $i$ and $B$ is the buyer’s budget, a nut-free box is the greedy pack

$$ \sum_{i \in \text{box}} p_i \le B $$

with any item whose allergen list contains nuts removed. Example: $B = 30$ → sourdough ($9$) + jam ($8$) + honey ($10$) $= \$27$ at Ann Arbor Farmers Market.

Makers also live under an annual cottage-food ceiling on the order of

$$ R_{\max} \approx \$50{,}000 \text{ per year} $$

so “bake as much as you can” is the wrong objective. The right one is “list what you can sell this Saturday.”

We also learned the hard Fetch lessons: an agent that is not on Agentverse with the Chat Protocol does not count; a hosted agent cannot see a laptop on hackathon Wi‑Fi; ASI:One will sit on “Reasoning…” forever if the editor has a bad indent; the first chat message often dies on cold start.

How we built it

Expo app (buyer + maker). React Native with Expo Router and NativeWind. Cream #FFF8F0, terracotta #C65D3B, sage #7A9E7E. Buyer tabs: Home, Box, Orders, Messages, Profile. Maker tabs: list, items, capacity, orders. Home is a radius slider, category chips, makers near you, and item cards with “$X$ left this week.” Checkout is a meetup spot + Saturday window, not a warehouse.

Server. Node backend in server/ on port 3001: GET /items, GET /meetup-spots, POST /orders, GET /forecast/:itemId, GET /health. Item fields include name, maker, category, price, allergens, left_this_week. Spots have name, address, lat/lng. Forecasts look like suggested $40$, sold $38$, reason “12 regulars + rainy Saturday + last 3 weeks avg 36.”

Rule layer. Michigan, Wyoming, and other locations in the profile toggle. Pickles and other acidified / low-acid foods fail the MI cottage check. Allowed baked goods, jams, granola, and honey pass. Label copy includes the home-kitchen disclaimer MDARD requires.

Fetch agent. fetch_agent/agent.py on Agentverse. Chat Protocol published. Discoverable as @michigan-cottage-com. Address agent1qfp4fke569p8elfchcezp2asr9zq9vvwcpq89d5nn7yfzatnag3kj3kw5c2. Profile. Repo: github.com/Sriram-Creator/MHacks.

What is real this weekend vs what is next. This is a working prototype: mock and snapshot catalog, meetup pickup, legal banners, maker capacity, ASI:One chat. Stock on the hosted agent does not decrement; order IDs are ORD-xxxxxx; the Agentverse process cannot hit http://35.3.150.195:3001 on venue Wi‑Fi. Next is a Cloudflare tunnel to live /items and POST /orders, then routing and more states as data, not as a rewrite.

Challenges we faced

Name and scope. The long-term product was a self-running weekly box. The weekend product is Savor: buyer-built boxes, public pickup, legality + forecast + chat. We cut delivery routes, 50-state admin, and “algorithm fills 200 boxes” so the demo we had was the demo we could stand behind.
Rapid concurrent integration. With multiple developers committing simultaneously on tight deadlines, managing shared state and avoiding breaking changes required strict build discipline and constant branch synchronization.