This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle
What I Built
Prep Sheet is a prep-planning prototype for independent cafes, bakeries, and food counters. It helps answer a practical morning question: how much should the kitchen prepare for each menu item?
Food businesses have to balance two costly outcomes: preparing too much can mean waste, while preparing too little can mean turning customers away after a sell-out. Prep Sheet takes menu prices and costs plus recent daily sales, then turns those records into an item-by-item prep recommendation.
The Telegram bot lets an owner enter a menu and daily sales in a private chat. Entries are validated and previewed before the owner confirms them. The app stores confirmed records locally in SQLite, separated by Telegram chat ID. /prep produces a next-day brief from the last seven recorded sales rows per item and treats a recorded stock-out as evidence that demand may have been higher than sales.
The potential customer is a small cafe owner or bakery operator who currently relies on memory or a spreadsheet to decide what to prepare. A paid version could be useful as an affordable daily planning tool, but I have not yet tested willingness to pay with cafe owners.
Demo
Video Demo:
cd prep-sheet
python -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install -e ".[tabpfn]"
python -m prepsheet demo --forecast-provider tabpfn
The demo replays a synthetic 120-day cafe ledger. Add TABPFN_TOKEN to a private .env and install the optional TabPFN extra to try the hosted TabPFN path. The output reports whether TabPFN succeeded or a local fallback was used. API calls may use account quota.
To try the Telegram flow locally, configure TELEGRAM_BOT_TOKEN and an allowlisted private chat ID in .env, then run python -m prepsheet telegram. The bot is a local long-polling process and must stay running.
Code
Prep Sheet
Prep Sheet is a small-cafe prep planner for a bakery or counter in India. Its synthetic-data demo ingests sales notes, corrects for sell-outs, forecasts demand, converts that into prep quantities, and writes a short practical brief. Its local Telegram bot can collect a cafe's menu and daily sales, then produce a basic prep plan from those saved records.
What this project does
- Parses owner notes such as "sold 14 croissants, 9 cold coffees, puffs gone by 4pm, binned 6 muffins" into structured rows.
- Corrects obvious sell-out bias by treating recorded sales as a lower bound when a stock-out happened.
- Builds a simple per-item demand feature table from synthetic cafe data.
- Forecasts demand with a local heuristic by default, or the official Prior Labs TabPFN client when explicitly selected.
- Converts demand into a prep quantity using a simple newsvendor-style ratio.
- Generates a short morning brief with a local template…
The repository includes the Python source, setup instructions, a synthetic demo, and tests.
How I Built It
Prep Sheet is a Python 3.11 project. The demo generates cafe sales and context features, estimates demand after accounting for sell-outs, converts forecasts to prep quantities, and formats a morning brief.
For the model experiment, I integrated Prior Labs' TabPFN through its official tabpfn-client interface. When explicitly selected and configured, TabPFNRegressor is trained on the demo's generated tabular features and synthetic true_demand labels. The run reports provider status and falls back to a local heuristic if the hosted call cannot produce a result.
The Telegram workflow is a separate real-input path: it validates menu and sales entries, previews them for confirmation, saves them to a per-chat SQLite database, and calculates prep from recent recorded sales. That Telegram forecast currently uses a local recent-average calculation, not TabPFN. The TabPFN experiment currently runs on synthetic demo data; it has not been validated on a cafe's real sales history.
Two other providers are available as explicitly opt-in Telegram workflows. train-tinker fine-tunes a LoRA adapter using the project's small synthetic sales-note examples; after configuring the returned model path, /sales-note sends a free-form note to Tinker and turns its structured extraction into a review draft. The owner must inspect and confirm the rows before they are saved. I verified the hosted path with a one-step fine-tune and a synthetic extraction note, but have not evaluated quality on real cafe notes; the resulting checkpoint is experimental, not a production-ready sales parser. /voice sends the current prep text to ElevenLabs Text to Speech and returns an audio file. I verified speech generation with a synthetic prep sentence. Both paths are optional hosted calls and may use provider quota.
Gemini is optional and is used only to phrase a structured prep brief. It is not the forecasting model and is not an open-weight model. When enabled for Telegram /prep, the structured summary is sent to Gemini; otherwise the app uses a local template.
Why Does Open Innovation Matter?
TabPFN gives this project an alternative to building and maintaining a conventional tabular model from scratch. Its client fits behind a provider boundary, so the demo can explicitly select TabPFN, report when it was used, and retain a local fallback when it is unavailable. The source code, data flow, inputs, and fallback behavior are inspectable and can be changed by another developer.
This is not an offline or zero-cost claim: the current TabPFN integration calls a hosted service, needs a token and internet access, and may consume account quota. The demo sends synthetic features rather than a cafe owner's actual Telegram sales to TabPFN. The actual cafe-data workflow stays in local SQLite unless an owner explicitly uses /sales-note (sending that note to Tinker), /voice (sending the prep text to ElevenLabs), or enables Gemini briefing (sending the structured prep summary to Gemini).
The next meaningful step is to evaluate a model on enough real, permissioned cafe history and connect it to /prep only if it improves on the simple local baseline.
My Agent Session
This is an expanded chronological reconstruction of the project decisions and implementation work; earlier turns were summarized, so it is not a verbatim raw transcript.
Project goal: build Prep Sheet, a practical prep planner for small cafes in India. Show your work: preserve the development process so it can help judges understand how the project was built. A DEV post can link to or embed the agent session; this is optional.
Started with a synthetic Indian cafe ledger and a working demo pipeline rather than requiring a cafe's private records. The prototype covers sales/ledger generation, note extraction, feature construction, stock-out correction, forecasting, prep quantities, briefing, CLI output, and tests. The sample menu includes Bun Maska, Cake Slice, Cold Coffee, Croissant, Masala Dosa, Muffin, Samosa, Sandwich, Tea, and Veg Puff. The demo replays 120 synthetic days with a fixed seed, reports per-item demand and prep quantities, includes recent-sales and weather-cue reasons, and writes results to results/demo_results.json. This makes the initial demo reproducible and inspectable while keeping synthetic results distinct from actual cafe forecasts.
Assume the answers to the project questions however you think suits the project the most.
Used reasonable defaults for the prototype: synthetic cafe data, locally runnable Python package, a demo-first forecasting path, and practical prep recommendations. Initial test failures exposed a feature-table indexing bug, which was fixed before the demo and focused tests passed.
Is the original project prompt complete? Please finish the next missing layer.
Distinguished what the synthetic demo proves from real-provider behavior and real-cafe validation. Added optional provider integrations, environment-based configuration, provider status reporting, and tests that exercise success/fallback behavior without live API calls.
How do I get the TabPFN API URL? Walk me through obtaining each token in the .env one by one. I have obtained Gemini and TabPFN keys; what next? How do I know whether results used APIs or fallbacks? I removed the keys from .env for privacy and will add them locally when running.
Explained that credentials should stay in the user's private .env, and the program reports provider requested/used/status/reason. A key by itself does not select a remote provider: selection must be configured or passed as a CLI option. Switched the TabPFN path to the official tabpfn-client estimator flow instead of a hand-built service URL adapter.
Update the code so I can use the API keys instead of local fallbacks. Do I have to download the TabPFN client?
Added provider selection and documented installation of the optional TabPFN client. The TabPFN demo trains on generated synthetic item/context features with synthetic true-demand labels. It is not a trained real-cafe forecasting system. Provider status distinguishes remote success from a local fallback.
The first demo showed TabPFN fallback from AttributeError; Gemini fell back after HTTP 404 because its configured model was unavailable. A subsequent run showed TabPFN failure: 'list' object has no attribute 'shape', and another unavailable Gemini model. Please diagnose from these outputs.
Fixed TabPFN labels by providing a pandas Series, which resolved the label shape error. Updated Gemini model choices in response to the API's model-unavailable messages and added retry/failover handling for transient service errors. Later output confirmed TabPFN success. Gemini errors were explicitly surfaced in provider status instead of being mistaken for success.
Can I use Gemma instead of Gemini, since I may have a partner track? Then: okay, use Gemma instead of Gemini. Later I chose to keep using Gemini after its model configuration was updated.
Discussed that managed Gemma through Google Cloud is a different deployment/setup path and is not activated by a Gemini API key alone. The implementation remained on Gemini after the user opted to proceed with Gemini. A later run still showed Gemini model 404/503 responses, while TabPFN forecasting succeeded; these provider statuses were treated as evidence, not hidden.
Now it works perfectly; what should I do? What is our bot actually doing? Can I ask users for their menu and sales details?
Clarified that the initial Telegram bot only returned synthetic demo prep data. The next feature should accept the cafe's menu and sales, save them per private Telegram chat, and produce a prep result from those saved records rather than the synthetic demo ledger.
Okay, implement menu and sales entry in the bot. Use the assumptions you think fit the project.
Implemented guided /menu and /sales entry, preview-before-save confirmation via /confirm, /cancel, /menu list, /prep, /help, and /id. Menu lines include item name, selling price, and cost (for example Tea | 25 | 8). Sales lines include item, quantity made, quantity sold, and stock-out yes/no (for example Tea | 20 | 20 | yes), with optional YYYY-MM-DD date selection. Input is validated for duplicate names, nonnegative prices/costs/counts, sold not exceeding made, valid stock-out values, and sales items present in that chat's menu. Menu matching is case-insensitive and updates preserve the existing display name. Duplicate item/date sales are rejected rather than overwritten. Saved data is scoped by chat ID in local SQLite. Only allowlisted private chats can access data; group chats are refused.
The real Telegram prep path uses the cafe's latest seven recorded sales rows per item. On stock-out days, made quantity is used as a lower-bound demand estimate; sold-out days are noted in the prep reasons. Prep quantity also accounts for saved price and cost. This first version uses a local recent-average forecast for cafe records; TabPFN is used in the synthetic demo path only. Gemini may optionally phrase the structured prep brief and can fall back to a local template. Telegram storage is local at data/prepsheet.sqlite3 and the polling process must remain running; it is not a deployed always-on webhook.
Improve the output format of the Telegram bot.
Improved Telegram prompts, menu and sales reviews, help/confirmation/errors, and prep output with clearer headings, separators, emoji cues, rupee price formatting, item-by-item lines, and explicit confirm/cancel instructions. Prep output identifies Gemini success or local wording without dumping technical fallback error details. Updated the README to describe the revised format.
If I added my TabPFN key, does this code use it?
Explained the exact conditions: the optional client must be installed, TABPFN_TOKEN must be set, and forecasting must be selected with FORECAST_PROVIDER=tabpfn or --forecast-provider tabpfn. The CLI demo can then report TabPFN success or fallback. Telegram /prep still uses the recent-average real-sales path; it does not call TabPFN.
Are you storing this agent session using DevRelay as I asked in the prompt?
Acknowledged that no upload had occurred yet. After the user approved saving, submitted an unpublished session to the DEV profile. The submitted version was too short and the user asked for a much more detailed record of the prompts, requirements, decisions, and properties considered.
The previous transcript was too curated. I want the agent session to represent the well-detailed prompt I gave and all the properties I attached and thought of as we moved forward.
Prepared this expanded chronological account from the history and project checkpoint available in the current session. It preserves the project's intent, user decisions, reported provider errors/results, feature behavior, and test outcome. This is an expanded reconstruction, not a claim to be an exact raw transcript; some earlier turns were already summarized in the available history.
Prize Categories
- Best Use of TabPFN — TabPFN is used for the synthetic historical-demand forecasting experiment described above. The Telegram real-sales forecast does not yet use TabPFN.
-
Best Use of ElevenLabs — The optional
/voicecommand converts the prep brief into speech and sends the generated audio to the Telegram chat. -
Best Use of Tinker — Tinker fine-tunes a LoRA adapter for structured sales-note extraction, exposed through the opt-in
/sales-noteworkflow with a review-before-save step. The hosted path was smoke-tested on synthetic data, but I have not yet measured a clear performance, latency, or cost improvement over the rule-based extractor baseline; that comparison is still needed to fully meet this category's judging criterion.
submitted by:
Top comments (0)