Inspiration

When a supplier recalls an ingredient lot, a small food producer has to answer one question fast: which customers received products made with it? Large manufacturers have traceability software. A bakery or a small dairy usually has spreadsheets, paper batch sheets and memory. The risk is not only slowness. It is orders that get missed, double-counted, or silently dropped because a record was incomplete. [Add one sentence of your own reason for choosing this problem.]

What it does

Batchline lets a producer ask, by voice or typed command, "trace flour lot LOT-FLR-2026-0117". It returns every batch that used the lot and every order that received those batches, grouped as collected, uncollected and incomplete (records with missing data are surfaced, never hidden). The producer then asks for a response plan: hold uncollected orders, draft notices for collected ones, flag incomplete ones. Nothing changes until they approve the draft. Approving twice never applies twice. Mistakes in a batch record can be corrected without erasing history.

How i built it Self-hosted MCP server (TypeScript, @modelcontextprotocol/sdk, Streamable HTTP) exposing 7 tools: record_batch, correct_batch_record, register_order, trace_ingredient_lot, preview_response, commit_approved_response, update_collection_status. DynamoDB single-table design with a lot-keyed GSI. Every multi-item write is a TransactWriteCommand with condition expressions, so races (duplicate batches, two people updating one order) resolve to exactly one winner. Idempotency records stop a repeated approval from re-executing. Corrections and collection changes are append-only audit items. Simulated Alexa+ experience in a web app: a voice page (browser speech recognition, with a typed fallback) sends commands to a Groq-hosted model that only routes to tools. Arguments are re-validated server-side against the same Zod schemas the tools use, and the model never invents an order ID. Next.js dashboard with orders, batches and a React Flow trace graph (lot → batch → order). Runs entirely on DynamoDB Local; an environment variable switches the same code to real AWS. Challenges Modeling two different ideas of order state (collectionStatus: did the customer pick it up, versus status: where the recall workflow stands). i conflated them at first and caught it late. Orders shared between two batches were double-counted in the trace summary and dropped from the graph (duplicate node ids). Fixed with distinct-order counting and batch-scoped node ids. Making concurrent writes safe and testable. iIproved it with a 10-round race test per tool. Building with no payment card, so no AWS account. Everything is developed and tested on DynamoDB Local. What I learned

Transactions and condition expressions in DynamoDB, designing an LLM layer that routes but never decides, MCP over Streamable HTTP, and writing tests that fail loudly (several of our bugs were hidden by "fixes" that silenced the symptom).

What's next

Real Alexa+ device integration, real AWS deployment, and message delivery for the approved notices.