Run your nutrition clients' weekly meal plans from one console

Build me a console I open through the week to run my nutrition clients' weekly meal plans, instead of rebuilding every plan by hand each Sunday. This is my working surface, not an unattended automation. Plans get built on demand when I click a button, and nothing reaches a client until I have read the plan and pressed Send myself. Design every screen around that: the app should always make it obvious what is a draft I still owe a decision on versus what has actually gone out.

The main view is a client roster read with Airtable List Records against my clients table. Each row shows the client's name, their dietary restrictions, their allergies, household size, delivery postal code, and the date their last plan went out. Pin anyone due this week to the top of the roster, where due means their last plan went out seven or more days ago or they have never had one. Put a clear badge on any client I have not sent anything to in over 10 days so the ones slipping through the cracks are impossible to miss. Restrictions and allergies belong on the row itself, not hidden behind a click, because they are the thing I scan for.

Opening a client gives me their detail view: their profile fields at the top, then their plan history underneath, read with Airtable List Records against a plan history table filtered to that client. Each past plan shows the date it was sent, the dinners it contained, and the recipe and grocery links that went with it. Above the history sits a Build this week's plan button that kicks off a background agent for that one client.

The agent's first step is Instacart Get Nearby Retailers for that client's delivery postal code, before it plans anything. The plan needs to name the stores that actually deliver to them, and there is no point building a plan a client cannot order. If no retailers come back, stop right there: do not select dinners, do not create any pages. Write a short note back to that client's row with Airtable Update Record explaining that no delivery coverage was found, surface that note on their card in the roster, and skip them. Note that this lookup covers US five digit ZIP codes and Canadian postal codes only, so check the format first and treat an unusable postal code the same way, as a skip with a note rather than a failed run.

With coverage confirmed, the agent selects the week's dinners. Dietary restrictions and allergies are hard filters, never preferences: an ingredient that touches an allergy or a restriction must not appear in a dinner or anywhere in the grocery list, and working around it with a trace amount is not acceptable. Read the client's plan history and exclude every dinner they received in the last two weeks so the rotation genuinely moves on. Scale ingredient quantities to their household size, and deliberately overlap ingredients across the week's dinners so the client buys fewer distinct items and wastes less food.

For each selected dinner, call Instacart Create Recipe Page to produce a shoppable recipe page with its ingredients and cooking instructions. Recipe ingredients go in the measurements field. Then call Instacart Create Shopping List Page exactly once for the whole plan, rolling every ingredient from every dinner into one deduplicated list where repeated ingredients are merged into a single line item at the combined quantity. The point of that single list is that my client checks out once instead of five separate times, so never generate a shopping list per recipe. Shopping list line items use line_item_measurements, not measurements, so do not reuse the recipe payload shape here.

Instacart only accepts a limited set of measurement units: each, lb, oz, g, kg, ml, L, cup, tbsp, tsp, and gallon. Anything else is rejected with a 4xx error, so normalize every quantity into the nearest supported unit before creating any page. Where a client's restriction field maps onto a supported health filter such as VEGAN, GLUTEN_FREE, ORGANIC, or KOSHER, pass it through onto the generated pages. Set expires_in generously, around 365 days, so links still work if a client comes back to an older plan. Both create calls return a products_link_url, which is the shareable page: store those URLs on the plan record and reuse them rather than regenerating a page every time a screen loads.

The agent finishes by writing the plan back with Airtable Update Record: the dinners chosen, the individual recipe links, the single grocery link, and the retailers that deliver to that client, all saved in a draft state that is explicitly not sent. The app then shows me that draft for review, so the agent's whole job ends at a proposal sitting in my queue.

My review screen lays out the drafted plan: every dinner with its ingredients and its recipe link, the one combined grocery link called out as the way to order the whole week at once, and the stores that deliver to that client. Every meal has a Swap control. Swapping asks the agent for a replacement dinner under the same restriction, allergy, and no repeats in two weeks rules, creates a recipe page for the new dinner, and then rebuilds the combined shopping list from scratch, because changing a dinner changes the deduplicated ingredient rollup. Save the revised draft back with Airtable Update Record. I may swap several meals before I am happy, so this has to work repeatedly on the same plan.

When the plan is right, a Send button emails the client with Gmail Send a Message: the week's dinners, each recipe link, the single grocery link highlighted as the fastest way to order everything at once, and the stores that deliver to them, written in a warm coaching voice rather than a system notification. Immediately after the send succeeds, call Airtable Update Record to stamp the sent date and the dinners used onto the client's row and the plan record, and refresh the roster so the change shows up right away: that client drops out of the due this week group and their attention badge clears without me reloading the app.

A few operational details. Airtable allows about five requests per second per base and batches of up to 10 records, so page through the roster rather than firing a request per client. Never let one client's problem take down the screen: a failed build, a missing postal code, or an empty retailer list should show as a note on that client and leave the rest of the roster working. Do not send a plan twice, and make an already sent plan visibly read only in the history so I cannot confuse it with a live draft.