• 

  App Overview

About the Project

Inspiration

Nourish Nearby was inspired by accounts from retirees describing how difficult it can be to find affordable food while living alone on a fixed income. A person living on Social Security may have a strict weekly budget, limited transportation, limited confidence with technology, and no family member available to compare dozens of store pages and assistance directories.

Most meal-planning apps begin with what someone wants to cook. Nourish Nearby begins with what the person actually has: a fixed budget, available cooking equipment, household size, and the ability to pick up groceries or receive delivery. Although I designed it with older adults in mind, the same simplified, large-text experience can help anyone who is food insecure, lives alone, or finds conventional grocery websites difficult to read.

I selected Sun City, Arizona, ZIP code 85351 for the pilot because it is a retirement community with a large older-adult population and a Fry's Food Stores location. Fry's is part of the Kroger family, which preserves a realistic path to an authorized retailer API in a future production version.

What it does

Nourish Nearby is a senior-friendly ChatGPT app that creates a practical grocery plan through a simple conversation. A person can start with an ordinary request such as “I have $40 and need food for three days.” The app then asks only for missing essentials: ZIP code, household size, usable cooking and storage equipment, whether the person has a can opener, allergies, pickup or delivery, and Kroger Boost status when it affects the delivery allowance.

The result includes exact products and package quantities, an integer-cent estimate, the amount left in the budget, and meal ideas tied to the groceries being purchased. It also reports exactly how many requested breakfasts, lunches, and dinners the selected packages can support using sourced product-label servings. If the budget cannot fund every requested meal, the app says so clearly and shows the shortfall instead of pretending the plan is complete.

The Sun City pilot can also show two reviewed local food-support services. Verified home-delivery programs are separated from other nearby services whose delivery status must be confirmed. Each result includes an official source, phone action, evidence-check date, and “call first” language for details such as hours or eligibility that can change.

The experience uses large text, high contrast, simple language, visible focus states, text labels that do not rely on color alone, and touch-friendly controls. It also includes a browser-based read-aloud guide for testing short spoken questions and concise meal summaries. During development, ChatGPT Voice did not invoke the app workflow, so voice remains an accessibility prototype rather than a claim about native Voice Mode support.

How I built it

I built Nourish Nearby with Codex (Sol 5.6) as my development partner, using TypeScript, React, the Model Context Protocol, Zod, Vitest, and Playwright.

The host model handles the conversational work: recognizing a natural request, collecting missing information, selecting the appropriate tool, and explaining results in plain language. A deterministic TypeScript planning engine owns the sensitive calculations. It filters products by available equipment, assembles practical meal patterns, reserves sourced servings for each planned meal occurrence, scales whole-package quantities, and performs every calculation in integer cents. The model cannot invent a product, alter a price, or change the calculated total.

The MCP server exposes five read-only tools for launching intake, planning groceries, finding food help, transitioning from a plan to assistance results, and rendering the final accessible view. The same domain logic runs through stdio for local Codex development and Streamable HTTP for ChatGPT. Zod validates the datasets and every tool input and output, while the widget remains independent from server internals through shared schemas.

For the pilot, I created a deterministic snapshot of 50 reviewed Fry's products spanning proteins, carbohydrates, vegetables, fruits, dairy, and meal bases. Product records preserve their official source, price evidence, package size, compatible equipment, and serving evidence when available. I also created a CatalogProvider boundary so this snapshot can later be replaced by Kroger's authorized Locations and Products APIs without rewriting the planner or interface.

I deployed the public demo on AWS. CloudFront provides one stable hostname, a private S3 bucket hosts the standalone interface, Lambda serves the deterministic browser API, and /mcp streams through an Amazon Bedrock AgentCore Gateway to an IAM-protected AgentCore Runtime. A CloudWatch invocation alarm can remove the public Gateway target after a configured request threshold, limiting the exposure and cost of the temporary judging endpoint.

Codex helped me throughout the project with product decisions, architecture, implementation, testing, accessibility audits, debugging, and deployment preparation.

Challenges I faced

The first planner was technically under budget but practically wrong. It selected unrelated cheap foods, left most of the budget unused, and suggested only one real meal. Later versions could overstate coverage by naming meals without proving that the purchased package quantities supported them. I replaced category-based “cheap item” selection with explicit meal patterns and serving-backed occurrence accounting. The app now calculates days × people × three meals, reports coverage by breakfast, lunch, and dinner, and returns an honest partial plan when the available budget or evidence is insufficient.

Retail data was another major challenge. Prices, promotions, inventory, delivery fees, ingredients, and pantry information can all change. Scraping retailer pages would not be a dependable production foundation, but I also did not have retailer API credentials for the judging build. I chose a repeatable official-page snapshot behind a provider interface and made uncertainty part of the data model. Missing facts remain unknown; product serving counts are used only when an exact source supports them; and allergy input fails closed because the fixture does not have reliable catalog-wide ingredient coverage.

The hosted MCP App also behaved differently from the local implementation in a few important ways. Tool names were namespaced by AgentCore Gateway, protocol headers were managed by the service, and one in-widget tool transition did not expose structuredContent in the same shape as the direct MCP client. I added Gateway-aware routing, strict output validation, and a validated text-envelope fallback for the widget bridge. I also found that the mounted ChatGPT iframe retained its old scroll position between results, which could make the first food-delivery card appear to be missing. Resetting the document scroll and adding explicit result counts made the transition understandable and testable.

Voice was a product challenge as well as a technical one. During testing, starting ChatGPT Voice did not trigger the app, and phone dictation could close the active widget. Rather than represent an unsupported experience as complete, I retained typed input inside the widget and built a separate browser-speech prototype that reads short questions and a concise result summary instead of reading the entire screen.

Time was another significant challenge. I did not discover the hackathon until two days before the deadline, so I had to move quickly from the initial idea to a working, tested, and deployable product.

Accessibility testing uncovered additional issues, including horizontal scrolling at 200% text size and insufficient dark-mode contrast. I revised the layout and color system and tested the experience across desktop and mobile views.

Deployment presented one final surprise: generated cdk.out directories were being included recursively in the Runtime's Docker context, causing CDK synthesis to become progressively slower. Excluding generated deployment artifacts reduced the context to the actual application files and made the final AgentCore deployment repeatable.

Accomplishments I’m proud of

• The canonical $40, three-day, one-person delivery scenario stays within budget at $37.95 and accounts for all 9 requested meal times with explicit package quantities and sourced serving evidence.
• The planner does not hide failure. Underfunded or equipment-constrained requests are labeled partial and show exactly which meal times could not be funded.
• The release dataset validates 1 Fry's store, 50 product records, 2 local food-support resources, and 53 provenance sources.
• The interface meets encoded WCAG AA contrast floors in light and dark themes, supports keyboard navigation and 44-pixel touch targets, and reflows at a 320-pixel viewport with 200% text without horizontal scrolling.
• The final local gate passes 121 unit, contract, integration, and widget tests. The browser suite also covers desktop and mobile layouts, accessibility scans, error states, focus visibility, and the self-contained MCP App resource.
• The deployed public MCP completed repeated end-to-end sessions covering launch, intake, planning, plan adjustment, food-help lookup, rendering, and resource loading.

What I learned

I learned that trustworthy AI products need a clear boundary between conversation and computation. The host model makes the experience natural, but deterministic code must protect prices, quantities, meal counts, and budget arithmetic. The model is most useful as the conversational coordinator, not as the source of changing facts or financial calculations.

I also learned that passing a schema is not the same as serving the user well. An early output was valid JSON and stayed below budget, yet it was still a poor grocery plan. Useful validation had to include domain semantics: meals must be recognizable, every ingredient must be named, instructions must identify the microwave or stovetop rather than say “use an appliance,” and purchased quantities must support the number of meals displayed.

Uncertainty is a feature when the alternative is false confidence. Modeling verified, call to ask, and unknown explicitly made both retailer and food-support results more honest. It also clarified where partnerships or live APIs would create the most value.

I also learned that accessibility must shape a product from the beginning. Designing for older adults influenced everything from typography and question length to error messages, voice-input options, and touch-target sizes.

Automated accessibility testing was especially valuable because visual intuition was not enough. Colors that looked readable still failed measured contrast, and a layout that worked at normal size overflowed when text was magnified. Encoding contrast thresholds and responsive checks turned accessibility from a design intention into a regression-tested requirement.

Finally, I learned that an MCP app is a complete distributed product, not only a tool definition. Tool discovery, host instructions, widget lifecycle, transport differences, cloud routing, resource loading, and graceful partial states all affect whether a simple natural-language request actually becomes a usable experience.

Most importantly, I learned how much can be accomplished in a very short period when the product scope is focused and Codex is used as an active development partner.

What’s next

The next technical milestone is an authorized, location-aware Kroger provider that refreshes store, product, price, promotion, and availability evidence before each plan while retaining the deterministic snapshot as a clearly labeled fallback. I would also expand the pilot to more ZIP codes and retailers without changing the core planning contracts.

For food assistance, I would invite local organizations to verify and maintain their own delivery areas, eligibility, hours, and costs. That would replace “call to ask” fields with current information while still preserving the call-first safety language for time-sensitive services.

Before enabling allergy-aware recommendations, I would require reliable ingredient and allergen evidence across the entire catalog. I would also conduct structured usability testing with older adults and people with low vision, then refine the question flow, language, and read-aloud experience from their feedback.

Longer term, I would like native app-aware voice support to let someone complete the same workflow conversationally while keeping the large, high-contrast visual result available for review. Purchasing, payment handling, and automatic substitutions would remain outside the product until they could be implemented with appropriate retailer authorization and safeguards.

Built With

• amazon-web-services
• codex