This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend
What I Built 🤟
Hey there, my name is Taqui. I am a fullstack web developer, and this time I wanted to build something useful outside my usual developer projects.
So I built TiffinTally, a small contribution to my friend’s family kitchen :)
The family story below is fictionalized. Customer counts and messages are illustrative, and real seller feedback is still pending.
The setup is a friend's family business in Noida, in the Gautam Buddh Nagar district of Uttar Pradesh, India. His mother and older sister prepare daily lunches for people who moved there for work.
Some customers live away from their families. They don't want restaurant food every afternoon. They want a simple home-cooked lunch that reaches them at the office
.
The business has around 18 to 24 monthly regulars. Small enough to know everyone, but enough for daily changes to become difficult.
You wonder,
What's the Problem i solving with this app ?
My Answer -
The cooking isn't the confusing part. The WhatsApp messages are.
“Aunty, no lunch tomorrow.”
“Please send two extra on Friday.”
“I am going home for three days.”
One person is cooking. Another is packing. A message arrives between both jobs.
Now someone has to remember the change, update the lunch count, tell the delivery helper, and account for it at the end of the month.
A missed cancellation means an extra lunch gets packed. A missed request means someone doesn't get theirs. And later, “I skipped those three days” becomes another chat to search.
TiffinTally keeps the request, the approved change, the packing list, and the monthly statement connected.
Customers can keep using WhatsApp. The kitchen gets a clearer way to manage what happens after the message arrives.
Demo
Live app: TiffinTally
Here is the workflow, one screen at a time.
1. Start with today's kitchen desk
The dashboard shows the selected service date, approved meal total, and requests waiting for review.
It has a personal greeting and a kitchen-notebook layout. I wanted it to feel like a working lunch register, not a dashboard full of unrelated charts.
2. Connect the kitchen's WhatsApp
The seller connects the kitchen phone through a QR code and links contacts to customer records.
Incoming messages from linked customers can be captured for review. Automatic analysis needs the AI providers configured.
There is also a manual “Add message” option.
3. Read voice notes too
Not every customer types their changes.
The WhatsApp audio path uses ElevenLabs Scribe v2 to turn a voice note into text. That text then enters the same review workflow.
This integration is implemented with mocked API tests. A live customer voice-note walkthrough is still pending.
4. Review before changing anything
The seller can read the original message beside the proposed change, check the dates and quantities, and edit or approve it.
Unclear requests stay marked for attention.
AI creates a draft. It does not approve the order.
5. Keep regular customers organized
Customer records hold names, packing notes, and schedules. Manual proposals handle changes that arrive through a call or conversation instead of WhatsApp.
Settings hold the kitchen timezone, planning time, cutoff, and customer limits.
Prices and delivery setup add each customer's agreed meal rate, billing number, building, and delivery note.
6. Finalize the packing sheet
Approved changes feed the daily packing quantities.
The seller finalizes a version of the sheet before handing it over. If current packing facts change, a fresh sheet is needed.
A pending draft cannot quietly change what gets packed.
7. Explain the monthly bill
The Bill book shows dated quantities and charges from finalized sheets.
Skips and extras reconcile into the total without deducting the same skipped meal twice. An agreed half-portion charge can be entered as a dated adjustment with a reason.
Issued statements are saved as immutable versions. Revisions reference the previous statement and warn customers not to pay both.
Sharing opens a WhatsApp composer for the seller to review and send. It does not mark a bill paid or prove a delivery happened.
8. Give the helper Ramesh Mode
Ramesh Mode groups positive meal quantities by the buildings or routes the seller entered.
Cancelled stops appear separately under “Do not stop today.” Unassigned deliveries remain visible instead of disappearing.
The helper gets a practical handover summary, not the whole billing workspace.
This is building-based grouping, not GPS route optimization.
9. Keep forecasts separate from orders
The forecasting section is advisory. It cannot change confirmed meals.
The planned TabPFN path uses historical meal changes and structured message signals. Hosted prediction integration and real-history validation are still unfinished, so I am not claiming a working demand forecast.
Code
Source repository: TiffinTally
How I Built It
I used Next.js, React, TypeScript, Tailwind CSS, and shadcn/ui for the app.
TanStack Query handles reads and refreshing data after actions. Better Auth provides Google sign-in. Zod validates inputs and model outputs.
Gemma reads the request
The configured model is Gemma 4 31B IT, accessed through Backboard using its OpenRouter provider.
It extracts proposed meal changes with supporting quotes from the original message.
The app checks those quotes against the source. A confident-looking answer with invalid evidence does not become an approved order.
JEV asks a different set of questions
TypeSafe's JEV, pinned to jev-1.13.0, independently classifies the request.
Is it a pause, a quantity change, or something unclear? Does it explicitly replace the regular schedule? Are necessary details missing?
Disagreement or uncertainty becomes a review warning. JEV is another signal, not a guarantee that Gemma is correct.
Backboard connects both stages
Both models use the Backboard SDK, with separate threads and memory disabled.
An approved fictional live test produced a validated review candidate through the Gemma/JEV pair. That checks the integration, not accuracy across real customer conversations.
MongoDB keeps the approved facts
The persistence layer targets MongoDB Atlas, using seller-scoped records, revision checks, transactions, and request receipts.
Approval and money calculations are ordinary application code, not model-generated arithmetic.
Amounts use integer paise. Repeated requests use idempotency keys. If a save result is uncertain, the UI checks the original receipt rather than blindly submitting it again.
The checks have limits too
I checked the layouts with 279 isolated browser-rendering cases, covering mobile, tablet, desktop, and short landscape sizes using fictional data.
Those checks do not replace watching someone use the app on their own phone. The authenticated seller walkthrough and real family handover remain next steps.
Why Does Open Innovation Matter?
Gemma is an open-weight model, so the extraction stage is not tied permanently to one closed model API.
I can inspect the prompts, change the validation, and evaluate another serving option without rebuilding the packing and billing rules.
A closed API could also extract messages. The benefit here is having more control over the model choice and the surrounding workflow.
Open-weight does not mean offline. This build uses hosted inference, and ElevenLabs transcription is hosted too.
The important boundary is visible in the code: models suggest changes, while the seller approves them and deterministic code calculates the result.
My Agent Session
I built TiffinTally with AI assistance in omnirush.ai.
The work included the review pipeline, billing reconciliation, delivery handover, and responsive layouts.
One useful failure was a Gemma quote with an incorrect evidence offset. The validator rejected it. I corrected the prompt and kept the strict check instead of weakening it to accept the answer.
Prize Categories
- Best Use of Gemma: Open-weight message extraction with source-linked review drafts.
- Best Use of Backboard: The shared SDK integration for the Gemma and JEV stages, tested with fictional live requests.
- Best Use of MongoDB Atlas: The application's persistence design for seller-scoped approvals, packing sheets, and statements. Live authenticated commerce verification remains pending.
- Best Use of ElevenLabs: Scribe v2 integration for WhatsApp voice-note transcription. Live end-to-end transcription remains pending. ElevenLabs
I am not claiming TabPFN or Sentry categories from configuration or unfinished integration alone.
The goal is pretty simple: let the family spend more time cooking, and less time figuring out which lunch changed.
Top comments (2)
Cool project brother
thanks mate, appreciate it