DEV Community: Manan Sharma

Prep Sheet: A Cafe Prep Planner

Manan Sharma — Tue, 13 Oct 2026 22:40:05 +0000

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

Scar3max / Prep-Sheet

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…

View on GitHub

The repository includes the Python source, setup instructions, a synthetic demo, and tests. It is licensed under MIT.

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.

Prep Sheet: Detailed Build, Provider Decisions, and Telegram Workflow

You

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.

Agent

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.

You

Assume the answers to the project questions however you think suits the project the most.

Agent

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.

You

Is the original project prompt complete? Please finish the next missing layer.

Agent

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.

You

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.

Agent

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.

You

Update the code so I can use the API keys instead of local fallbacks. Do I have to download the TabPFN client?

Agent

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.

You

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.

Agent

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.

You

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.

Agent

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.

You

Now it works perfectly; what should I do? What is our bot actually doing? Can I ask users for their menu and sales details?

Agent

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.

You

Okay, implement menu and sales entry in the bot. Use the assumptions you think fit the project.

Agent

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.

▸ pytest pytest -q

Input

pytest -q

Output

The first suite run exposed Windows SQLite database files that remained open during temporary-directory cleanup. Replaced connection lifetime handling with a closing context manager; 19 tests passed.

Agent

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.

You

Improve the output format of the Telegram bot.

Agent

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.

▸ pytest pytest -q

Input

pytest -q

Output

19 passed. Pylance/file diagnostics reported no errors in the changed Python files.

You

If I added my TabPFN key, does this code use it?

Agent

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.

You

Are you storing this agent session using DevRelay as I asked in the prompt?

Agent

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.

You

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.

Agent

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 /voice command 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-note workflow 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.
Best use of GitHub Copilot — I used GitHub Copilot as a pair programmer to build Prep Sheet’s end-to-end café planning workflow—from turning free-form sales notes into structured records to correcting for sell-outs, forecasting demand, and generating prep plans in Telegram. I reviewed and tested suggestions, kept hosted AI features opt-in with local fallbacks, and made sure extracted sales aren’t saved until the user confirms them.

submitted by:

Manan SharmaFollow

/scar3max

Grass Forecast - Turning Bike-Share and Weather Data into a Reason to Touch Grass

Manan Sharma — Sun, 11 Oct 2026 11:07:58 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Grass Forecast helps people find a reason to step outside—even when the latest activity data is delayed.

The project uses public Chicago Divvy bike-share data and weather information to forecast outdoor activity. When activity data is fresh, it predicts whether tomorrow is likely to be a high-activity day and identifies a likely busy time window. When Divvy’s published data is stale, it switches to a separate ride-count estimate, labels it clearly as an estimate, and shows how old the source data is. If an activity estimate isn’t available, the dashboard can still suggest an outing based on the weather.

The idea is to make the forecast useful without pretending an estimate is an observation. Grass Forecast also generates a short, weather-aware nudge to make going outside feel more approachable.

Demo

Video Demo:

Code

Scar3max / GrassForecast

Grass Forecast

Grass Forecast is a tiny outdoor-day forecaster built for the Touch Grass challenge. It learns from public outdoor activity data and historical weather to estimate whether tomorrow will be a high-activity day, which window is likely busiest, and then writes a short spoken nudge.

What this does

Pulls Chicago Divvy bike-share activity data from the public Divvy bucket
Fetches historical daily weather for the training period and tomorrow's forecast from Open-Meteo for Chicago
Builds a daily feature table with leakage-safe history and weather features
Evaluates with expanding, time-ordered walk-forward folds and compares against three baselines
Uses TabPFN when its token is configured and available; otherwise labels the scikit-learn fallback explicitly
Generates a short, conversational nudge with Gemma through the Gemini API or a local fallback message, including a weather-aware estimate-based nudge when activity data is stale
Converts fresh-data and stale-estimate nudges to short audio files with ElevenLabs when…

View on GitHub

How I Built It

Grass Forecast has a Python and FastAPI backend with a React dashboard. It collects public Divvy trip data and weather data from Open-Meteo, then prepares daily and hourly activity features for forecasting.

The project uses two distinct approaches rather than treating missing recent data as if it were current:

With fresh activity data, it uses a high-activity classifier and estimates the busiest window.
With stale data, it uses a separate ride-count estimator for targets up to 30 days beyond the latest observation. The dashboard shows the activity-through date, data age, forecast lead, and estimated count.

The stale estimate is directional, not measured activity. Its displayed model range is not a calibrated prediction interval, and the historical weather evaluation uses observed weather rather than archived day-ahead forecasts—so those results may be optimistic.

For AI, I use the open-weight Gemma 3 4B model through the Gemini API to generate a concise, conversational nudge. The project also supports TabPFN for classification when configured, with a clearly labeled scikit-learn fallback.

Why Does Open Innovation Matter?

This project depends on being able to combine and inspect tools from different parts of the ecosystem: public activity data, open weather data, open-weight models, and open-source application frameworks.

That flexibility helped me build a system that can adapt when one source is delayed. Instead of hiding the gap or returning nothing, Grass Forecast can switch to a clearly labeled estimate or offer a weather-based idea. Open tools also make it easier to see where the data comes from, what is processed locally, and where hosted AI services are involved. That transparency matters when a forecast could otherwise look more certain than it really is.

Prize Categories

Best Use of TabPFN
Best Use of GitHub Copilotx
Best Use of ElevenLabs
Best Use of Gemma

Published by -

Manan SharmaFollow

/scar3max

PrepPal: How I Built an Adaptive, Open-Source AI Mock Interviewer for My Anxious Batchmate

Manan Sharma — Fri, 02 Oct 2026 06:35:48 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

Every placement season on campus, the same story unfolds: brilliant engineers who can write flawless code freeze up the moment an interviewer asks them to explain concepts out loud.
My close friend and college roommate is one of those engineers. Despite knowing distributed systems and algorithms inside out, mock interview anxiety was getting the best of them. Commercial mock platforms were either expensive paid subscriptions, static LeetCode question banks, or generic AI chatbots that write 3-paragraph lectures instead of behaving like a real, conversational interviewer.
To help my friend prepare without the fear of judgment or high fees, I built PrepPal (Adaptive Performance-Based Technical Interview Bot) — an intelligent, conversational mock interviewer that adapts to how well the candidate is actually doing in real time.

Key Capabilities:

Natural, Concise Dialogue: Follows strict conversational pacing (one short follow-up at a time, zero lecturing, and a filter that bans robotic phrases like "Let's shift gears").
Behavioral & Hesitation Detection: Actively catches filler words ("umm", "uh", trailing off), evasive non-answers, or blank spots, immediately softening the follow-up instead of penalizing blindly.
Dynamic Difficulty & Pivoting: Computes a real-time momentum score across answers. If my friend is acing a topic, it escalates to expert architectural trade-offs; if they hit a wall, it smoothly pivots to another technical domain.
Glassmorphism Analytics Dashboard: Gives immediate feedback badges and post-interview Plotly visual performance reports.

Demo

interview-framework.onrender.com

What my friend said after testing it:

"It doesn't feel like talking to ChatGPT. When I hesitated on Python decorators, it didn't write me an essay — it just gave me a gentle nudge to explain simple functions first, exactly like our campus placement rounds."

Code

Scar3max / MiniProject

🎯 Adaptive Performance-Based Interview Bot

An AI-powered technical interview companion that dynamically adjusts its questions, difficulty, and topics in real-time based on the candidate's answers. Built with a hybrid Edge-Cloud LLM architecture utilizing a local Small Language Model (SLM) for drafting and the Groq API for strategic evaluation.

✨ Features

Hybrid Edge-Cloud Architecture: Combines local Qwen2.5-7B-Instruct SLM (via Llama.cpp) and cloud-based Groq API.
Dynamic Difficulty & Pivoting: Automatically detects knowledge gaps, hesitation patterns, and performance trend signals to adjust difficulty or pivot sub-topics.
Real-Time Badges: Displays immediate feedback (e.g., Good Answer, Vague, Incorrect, Hesitation) as the candidate responds.
Rich Analytics Dashboard: Renders interactive Plotly charts showing score trends, answer quality distribution, and personalized qualitative AI feedback.
Natural Tone Enforcement: Automatically monitors and filters robotic transitions to keep the dialogue conversational and human-like.

🛠️ Tech Stack

Frontend: Streamlit (Glassmorphism dark theme)
…

View on GitHub

How I Built It

Local Edge SLM (Fine-Tuned Qwen2.5-7B-Instruct):

Fine-tuned on our own campus technical interview dialogue dataset.
Quantized to Q4_K_M GGUF and executed completely offline on consumer hardware via llama-cpp-python (llama.cpp) using the ChatML prompt specification.
Serves as the rapid triage engine: produces instantaneous 12–18 word probing follow-ups and emits a dedicated [CONFIDENCE_LOW] token if the candidate's answer indicates struggle or hesitation.

Open Cloud Reasoning (Qwen 3.8 27B via Groq):

Handles parallel answer evaluation (strict 0.0–10.0 numeric scoring + diagnostic classification) with sub-second latency.
Powers dynamic topic syllabus generation with an SQLite persistent caching layer.

Open-Source Stack:

Frontend: Streamlit with custom Glassmorphism dark CSS.
Inference Harness: llama-cpp-python, Groq SDK.
Visualization: Plotly for real-time candidate score trajectories and competency distributions.

Why Does Open Innovation Matter?

This project could not have succeeded on proprietary, closed-source foundation models alone:

Custom Fine-Tuning for Specialized Agent Behavior:
Closed APIs often refuse to output strict sentinel tokens or insist on polite, verbose conversational fillers. Open weights allowed us to fine-tune Qwen2.5-7B specifically on campus placement conversations, conditioning it to reliably output single control tokens like [CONFIDENCE_LOW] when candidates freeze up.
Local Edge Inference Means Zero Anxiety & Complete Privacy:
Job interview preparation is deeply vulnerable. By running our triage model locally in quantized GGUF format on a laptop, mock interview transcripts don't have to be harvested into commercial training sets. It works even on poor campus Wi-Fi with no internet dependency for drafting.
Freedom to Evolve Without Lock-In:
During development, we completely swapped our local SLM from Phi-3 to fine-tuned Qwen2.5, and migrated cloud reasoning to open-weight Qwen 27B without touching our core orchestration state machines. Open weights give builders sovereign control over their AI infrastructure.

Prize Categories

1)Best use of Render
2)Best use of Github Copilot

Submitted by: scar3max