Ansh Meshram

Posted on Oct 17

From Leftover Rotis to Better Margins: Building DabbaIQ with Open-Source AI

#devchallenge #hf26challenge #ai #opensource

Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle Submission 💸

This is a submission for the Hacktoberfest Open-Source AI Challenge — Week 2: Side Hustle.

A kitchen rarely loses money in one dramatic moment. Sometimes it leaks out one extra batch of rice, one ingredient bought too late, or one tray of food that nobody counted after lunch.

For a small tiffin business, those decisions are connected. Demand affects preparation. Preparation affects stock. Stock and recipes affect cost. Sales and leftovers should affect tomorrow’s plan. But in a busy kitchen, those facts often live in different notebooks, spreadsheets, or someone’s memory.

I’m building DabbaIQ to connect those decisions in one kitchen operations desk.

The guiding idea is simple: Cook the right amount. Waste less. Earn more.

What I Built

DabbaIQ is an AI-assisted kitchen operations platform designed for Indian tiffin services, meal-subscription businesses, small caterers, and cloud kitchens. It brings together the daily workflows that decide whether a kitchen runs smoothly—and whether the economics make sense.

Preparation planning: organize demand inputs, preparation quantities, safety buffers, and ingredient availability before the rush.
Inventory and procurement: track ingredients, spot low-stock risks, and support supplier or market-price discovery.
Recipe costing: connect ingredient quantities to estimated per-portion and per-dabba costs.
Sales and dispatch: record what went out, instead of treating production as proof of sales.
Waste tracking and reporting: record leftovers and compare operational outcomes to help inform the next shift.

The product also has a visual identity rooted in the dabba itself: a stainless-steel four-tier tiffin. The introduction follows a scroll-driven, tier-by-tier sequence, using each layer to introduce part of the system. It’s a product explanation, not just a generic dashboard with an AI badge added to it.

DabbaIQ is a working software project, but I’m not claiming that it has already reduced waste by a measured percentage or generated revenue for a paying kitchen. Those are outcomes to validate with operators—not numbers to invent for a launch post.

Demo

Live frontend: https://dabba-iq.vercel.app/

The frontend is deployed. I’m completing production checks on the backend’s database access, cross-origin configuration, and AI endpoint so I can verify the complete workflow—not just the interface. Until those checks pass, treat the link as a preview and not a guarantee that every backend-connected action is working end to end.

Code

GitHub repository: https://github.com/AnshMeshram/dabbaiq

AnshMeshram / DabbaIQ

AI-powered kitchen prep & food waste planner for tiffin services and caterers. Cuts food waste with smart demand forecasting, live SerpAPI wholesale ingredient price discovery, MongoDB Atlas persistence, and resilient Temporal-orchestrated preparation workflows.

🍱 DabbaIQ — AI Kitchen Prep & Food-Waste Planner

"Cook the right amount. Waste less. Earn more."

An enterprise-grade, open-weight AI kitchen operations desk built for Indian tiffin subscription services, cloud kitchens, and meal prep entrepreneurs. Designed from a 26-screen Google Stitch canvas, pairing deterministic demand forecasting with Gemma 3 open-weight reasoning.

🚀 Live Web App (Vercel) • 🍱 3D Tiffin Experience • 📐 Architecture • ⚡ Quickstart • ☁️ Deployment • 🧪 101/101 Tests

📑 Interactive Table of Contents

Click to expand / collapse navigation

View on GitHub

How I Built It

DabbaIQ is split into a web interface, an API layer, operational data, and optional intelligence/workflow services.

Frontend: Next.js, React, TypeScript, and Tailwind CSS.
Backend: Python and FastAPI.
Application data: MongoDB Atlas.
Open-weight AI path: Gemma 2 through Ollama for supported local-inference and kitchen-assistance workflows.
Market research integration: SerpAPI for supplier and market-price discovery.
Time-series capabilities: Tiger Data/TimescaleDB for historical data workflows.
Workflow orchestration: Temporal integration for processes that benefit from coordinated execution.

The most important design decision is the boundary between calculation and interpretation. Ingredient quantities, stock counts, arithmetic, and report totals should be derived from structured records and application logic. A language model can help interpret an unstructured kitchen note, explain a recommendation, or make a plan easier to understand; it should not be allowed to make up stock counts or quietly replace a calculation.

That boundary is what makes an AI tool useful in an operational setting. A fluent answer is not enough if the number behind it is wrong.

The system is designed as a feedback loop: records inform a plan; the kitchen executes it; sales and leftovers become new records. The value is not one isolated prediction. It is making the next decision with better context than the previous one.

Why Does Open Innovation Matter?

For a small business, the model choice is not just a technical preference. It affects operating cost, deployment choices, control over data flow, and how much the product depends on one provider.

Gemma 2 is an open-weight model. Running it through Ollama gives the project a path to local inference in environments where the model, hardware, and configuration are available. That makes it possible to experiment with the model locally, inspect the surrounding application code, and change the inference setup without rebuilding every product workflow around a single closed API.

Open-weight does not automatically mean free, private, or production-ready. Local inference still uses hardware. A hosted service still needs a reachable, secured model endpoint. And a privacy promise is only as strong as the actual data flow. I want DabbaIQ to make those deployment choices explicit rather than market “AI” as magic.

The open approach also lets the system keep its most important business rules outside the model. The database and deterministic calculations remain the source of truth; the model adds assistance where language and context are useful. That separation makes it easier to test, replace, and improve individual components over time.

Why This Could Be a Side Hustle

DabbaIQ is aimed at a narrow customer, on purpose: an independent kitchen that has outgrown notebooks but cannot justify a large restaurant-management system.

Potential customers include:

Tiffin and meal-subscription operators preparing recurring batches.
Small caterers coordinating ingredients, portions, and dispatch.
Cloud kitchens trying to understand ingredient cost and leftovers.
Meal-prep businesses that need a clearer link between sales and preparation.

The business model I would test first is a per-kitchen monthly subscription, with a simple entry tier for planning and stock visibility and a higher tier for costing, reporting, and more advanced assistance. An initial price experiment might be ₹499–₹999 per kitchen per month—but that is a hypothesis to test, not a price customers have agreed to pay.

The value proposition should be measurable. During a pilot, I would compare planned portions with actual sales and leftovers across several shifts, record how often stock shortages disrupt preparation, and ask the operator whether the tool saves enough time or money to justify paying for it. If it cannot show that value, the product needs to improve before the pricing does.

What I’m Validating Next

I don’t have a paying pilot or verified savings figures to report yet, and I won’t manufacture a testimonial or ROI claim. The next milestone is to work with a real kitchen operator and test the workflow against real shift records—with permission, and without exposing customer or business data unnecessarily.

The immediate engineering work is equally practical: verify MongoDB connectivity in the deployed environment, allow the correct Vercel origin through CORS, and make sure the configured Ollama/Gemma endpoint is reachable before presenting AI features as online. A deployment is not complete just because the homepage loads; the critical actions have to work too.

My success metric is not whether the model writes an impressive explanation. It is whether a kitchen owner can make a better preparation or purchasing decision because DabbaIQ connects information that was previously scattered.

Prize Categories

I’m submitting for the overall Side Hustle challenge. I’ll select a partner prize category only where the corresponding technology is meaningfully integrated and can be demonstrated in the final build—not simply because a dependency appears in the repository.

Closing Thought

A small kitchen doesn’t need AI for the sake of AI. It needs fewer avoidable surprises: fewer last-minute stock gaps, a clearer cost per dabba, and a more useful account of what happened after the lunch rush.

That’s the problem I’m building DabbaIQ for. The next step is to test it with the people who live that problem every day.

Live frontend: https://dabba-iq.vercel.app/

Source code: https://github.com/AnshMeshram/dabbaiq

DEV Community