StockWise

We didn't build new infrastructure, we networked the one that already exists.

Comment

-> Inspiration Over 300,000 DC residents live in food deserts, concentrated in Wards 5, 7, and 8. Supermarkets are miles away. But corner stores? They're already there, on nearly every block. The problem isn't infrastructure. The problem is coordination. Corner store owners want to stock what their community needs, but they're flying blind — no demand data, no supply chain support, no way to know what to order until shelves are already empty. Meanwhile, DC Central Kitchen (DCCK) is doing heroic work delivering fresh produce, but without real-time signals from the ground, their bulk orders are educated guesses at best. We asked: what if the corner store wasn't just a store — but a node in a city-wide food distribution network? That question became StockWise.

-> What We Built StockWise is a full-stack platform that creates a three-way feedback loop between customers, corner store owners, and DCCK — turning reactive stocking into demand-driven distribution. The 3-Tier Fulfillment Engine The heart of StockWise is a real-time fulfillment engine. When a customer requests an item: Tier 1 — Pickup (same ward): Item is reserved immediately at a nearby store. Tier 2 — Transfer (cross-ward): Item exists in another ward. StockWise triggers an inter-store transfer with a shared economics model so everyone benefits. The customer pays the markup but immediately receives a coupon equal to it — so the effective price is unchanged. The source store earns a 10% commission for supplying the item. No party loses. Tier 3 — DCCK Delivery: Nobody in the network has it. The request is escalated to DCCK's next delivery cycle, and the demand signal is logged.

->Demand Intelligence

Every request and community vote is aggregated into a demand score per item per ward. When a score crosses a threshold, the DCCK dashboard flags it for bulk order consideration — turning bottom-up community signals into top-down supply chain decisions. AI Chatbot (Gemini-powered) A natural language assistant with live database access — not a static FAQ bot. It queries real inventory and sales data in real time, serves both customers ("where can I find plantains near Ward 7?") and store owners ("what are my top-selling items this week?"), and maintains multi-turn conversation history with retry logic for API resilience. Store Owner Tablet A touch-friendly interface for recording sales (with SNAP/EBT tracking), viewing low-stock alerts, and listing excess inventory on a community marketplace before it expires — reducing food waste while generating extra revenue. DCCK Dashboard Network-wide analytics: sales by store, SNAP adoption rates, demand signals aggregated from requests and votes, and automatic flagging of stores with zero SNAP activity — helping DCCK identify where support is most needed.

-> How We Built It LayerTechnologyWhyBackendNode.js + ExpressFast API development, great MongoDB ecosystemDatabaseMongoDB + MongooseFlexible schema for evolving data modelsAIGoogle Gemini 3 FlashFast, capable, multi-turn conversation supportFrontendVanilla HTML/CSS/JSZero build tooling — ship fast at a hackathonChartsChart.jsLightweight, great for dashboard analyticsDev DBmongodb-memory-serverZero-config local dev, auto-seeds demo data We structured the backend around clear separation of concerns — models, routes, and a central server.js that wires everything together including the Gemini chat endpoint with retry logic for API overload scenarios. The transfer economics model was designed to be mathematically fair by construction: the coupon amount is always exactly equal to the markup, so the customer is made whole regardless of where the item comes from.

-> Challenges We Faced Designing the economics model was the hardest conceptual challenge. A naive transfer fee would penalize customers in food deserts for living in the "wrong" ward — which defeats the entire mission. We iterated until we landed on the coupon-offset model where the transfer markup is real (to incentivize stores) but fully refunded to the customer (to preserve access equity). Dual schema complexity emerged as the project grew. We ended up with two store schemas — a lightweight Store used by the fulfillment engine and seed data, and a detailed CornerStore with full metadata (hours, SNAP/WIC flags, contact info). Keeping these in sync required careful middleware in server.js to detect which schema held live data. Gemini API rate limits hit us during demo prep. We built exponential backoff retry logic directly into the askGemini helper — 3 attempts with 2s/4s/6s delays — so the chatbot degrades gracefully under load instead of crashing. Scoping the AI chatbot was a UX challenge. Giving it raw DB access is powerful but risky — we had to carefully craft the system prompt to keep responses focused, plain-text formatted, and always including store name, address, price, and stock quantity when relevant.

-> What We Learned

The infrastructure already exists. The most impactful solutions often don't require building new physical infrastructure — they require networking what's already there. Economic incentives matter as much as the technology. A technically perfect system that doesn't give store owners a reason to participate will fail. The commission model was as important as any line of code. Demand signals are a public good. Aggregating community votes and requests doesn't just help DCCK — it gives every store owner in the network better information than they'd ever have alone. Ship fast, then harden. mongodb-memory-server let us build and demo with zero infrastructure setup. The AI retry logic was added after we got burned once — real-world resilience is always an afterthought until it isn't.

-> What's Next

SMS-based requests for residents without smartphones (critical for true accessibility) SNAP/EBT coupon integration so transfer coupons are redeemable at point of sale Predictive restocking using historical request + sales data to recommend order quantities before stockouts happen Live pilot with one DCCK partner store in Ward 8

Built With

Share this project:

Updates