FreshRoute-AI: Predict Demand, Reduce Waste, Deliver Smarter 🌱

This is a submission for the Hacktoberfest x AWS sbg bzu Food can be available and still fail to reach the people who need it. A farmer may have produce with only a few good days left. A buyer may be searching for that same produce at an acceptable price. Between them are fragmented information, uncertain demand, and delivery decisions that are still handled manually. I built FreshRoute-AI to explore a practical question: can one transparent workflow connect surplus farm inventory to buyer demand, reserve the stock safely, and turn the match into a usable delivery plan? I started the project during Hacktoberfest x AWS SBG BZU, where I was selected as a hackathon winner. The hackathon version proved the concept. Since then, I have continued turning it from a presentation into a deployed, tested marketplace. What I Built FreshRoute-AI is a full-stack agricultural marketplace and logistics planning platform. It gives farmers, buyers, and operators a shared workflow: A farmer lists produce with quantity, price, location, and remaining freshness days. A buyer posts a requirement with desired quantity, location, and maximum price. The matching engine finds compatible supply and ranks it using fulfillment, location, price, and freshness. The buyer reserves stock through an atomic database transaction. The delivery planner requests road geometry and stop ordering from OSRM. The Impact Center separates completed reservations from projected rescue opportunities. The distinction in that last step matters. I did not want a dashboard that presented every possible match as food already saved. FreshRoute reports a reservation as realized activity only after it exists in the database. Matchable kilograms and potential farmer revenue remain clearly labeled projections. Architecture flowchart LR U[Farmer / Buyer] --> R[React + Vite interface] R --> F[FastAPI application] F --> M[Marketplace and matching engine] F --> A[Gemma assistant adapter] F --> O[OSRM routing adapter] M --> P[(PostgreSQL in production)] M --> S[(SQLite for local development)] P --> I[Impact Center] O --> L[Leaflet route map] The frontend is a React application split into lazy-loaded views for the dashboard, farmer portal, marketplace, forecasting, impact, logistics, and AI assistant. FastAPI exposes the APIs and serves the Vite production build from the same deployment. PostgreSQL provides durable production storage, while SQLite keeps local setup simple. Matching without pretending everything is AI One of my most important design decisions was to keep the marketplace matching deterministic. Produce names are normalized, including aliases such as tomato, tomatoes, and tamatar. A candidate must have stock available and fit the buyer's maximum price. Its ranking then combines: fulfillment coverage: 45% location relevance: 25% price advantage: 20% freshness urgency: 10% The Impact Center adds an urgency-first allocation pass. It tracks remaining stock and remaining demand so the same kilogram cannot be counted for two buyers. That makes its opportunity figures reproducible instead of optimistic marketing numbers. Demo vedio: https://youtu.be/-UddXQMCx-A Live demo: freshroute-ai-nine.vercel.app GitHub repository: humairtariq08-coder/freshroute-ai Official hackathon submission: Freshroute-ai on MLH Gemma 4 The partner technology I can verify in the implementation is Google-hosted Gemma 4. I selected Gemma because the marketplace needed explanations in addition to calculations. The matching engine should decide which records qualify, but an assistant can help a user understand demand, describe produce, interpret forecast assumptions, or summarize delivery options. The adapter in backend/gemma.py calls Google's documented generateContent endpoint. It supports chat, listing descriptions, forecast explanations, matching explanations, logistics recommendations, and optional produce-photo descriptions. I added several guardrails: only documented Gemma model identifiers are accepted; the API key remains on the backend; marketplace records are supplied as data, not trusted instructions; required task inputs are validated; photos are restricted by MIME type and size; the app never substitutes a fake AI answer when the provider is unavailable. Hackathon Experience I built FreshRoute-AI during Hacktoberfest x AWS SBG BZU under the time pressure that makes hackathons both difficult and valuable. I had to decide which parts required real engineering and which parts needed an honest boundary around them. The event pushed me to connect multiple disciplines: agricultural marketplaces, AI assistance, forecasting, geospatial routing, accessible frontend design, and deployment. Winning the hackathon was meaningful, but the more important result was realizing that the prototype had enough depth to continue developing. I also used AI-assisted development responsibly. AI helped accelerate debugging, implementation, and documentation, but I still verified behavior with tests and live deployment checks. I did not treat generated code or generated explanations as proof that a workflow worked. That mindset changed the project after the event. SQLite became managed PostgreSQL in production. Simple matching gained explicit ranking factors. The forecast gained walk-forward evaluation. The deployment gained health checks, configuration validation, and a public evidence trail. Evaluating a small forecast honestly FreshRoute compares a moving average with exponential smoothing. It performs expanding-window, one-step-ahead evaluation and selects the method with the lower mean absolute error. The included demand history is synthetic, so I describe this as a reproducible baseline—not a validated business forecast. That limitation is more useful than an impressive but unsupported accuracy claim.