DEV Community: Avrojit Dutta

ReplyLater: I Gave My Inbox the Night Shift to Reclaim My Me Time

Avrojit Dutta — Sun, 25 Oct 2026 12:37:10 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

ReplyLater: The Overnight Email Co-Pilot

The Sloth Philosophy: Sloths don't hurry, stress over backlogs, or react to every stimulus in real time. They pace themselves, conserve their energy, and let the world catch up.

Go to sleep with an inbox full of obligations. Wake up with next week's replies ready.

What I Built

ReplyLater is a local-first, open-source AI co-pilot that turns a chaotic email backlog into an organized, week-ahead action board.

Most AI email tools compete for your attention while you're already trying to read and respond. ReplyLater takes a different approach: batch the work, let it run in the background, and review the results when you're ready.

The workflow is simple:

Import an unread .eml backlog or email export.
Let ReplyLater process the conversations.
Review the results in three buckets:
- Needs Your Call: Emails that need your judgment or missing information.
- Week-Ahead Queue: Reply drafts and extracted commitments organized for the coming week.
- Info / Closed: Receipts, digests, and other messages that don't need a reply.

ReplyLater can classify messages, extract commitments such as “Send the revised design deck by 2 PM,” identify unanswered questions, and prepare reply drafts. When key information is missing, it is designed to flag the uncertainty rather than invent an answer.

The people who benefit are anyone who ends the week with an inbox full of obligations: students, freelancers, developers, and busy professionals who want to spend less energy on inbox triage and more time on meaningful work.

Demo

🚀 Live Demo: https://replylater.onrender.com
🎥 Walkthrough Video: Watch the 60-Second Demo

The hosted demo may have different privacy characteristics from a local installation. Use synthetic or non-sensitive email samples when testing a hosted instance unless its data-handling behavior has been verified.

Code

💻 GitHub Repository: github.com/avrojitduttaj/replylater

The project is organized around a React dashboard, a FastAPI backend, local model inference, durable workflow orchestration, and persistent semantic memory.

How I Built It

ReplyLater is built as a modular, local-first application:

Frontend: React, Vite, Tailwind CSS, Lucide Icons, and TanStack Query.
Backend: FastAPI, Python, and SQLAlchemy Async.
Open-weight AI: Google's Gemma 2B (gemma2:2b), running locally through Ollama.
Durable orchestration: The Temporal Python SDK (temporalio).
Semantic memory / RAG: PostgreSQL with pgvector, using Tiger Data.
Observability: Sentry Python SDK with custom inference and workflow spans.

🛠️ Agent Build Log (DevRelay)

We recorded and saved the entire agent session transcript and architectural reasoning using DevRelay.

🔗 Full Agent Session & Trace:

ReplyLater: Local-First Email Assistant Verification

You

Inspect ReplyLater and verify its Python environment, FastAPI backend, React frontend, Ollama/Gemma, Temporal, Sentry, tests, and relevant DEV/MLH opportunities. Prepare technical documentation, but do not publish or submit anything without permission. Do not include secrets, tokens, DSNs, private environment values, private machine paths, or email content in a public session.

Agent

Repository inspection found a React/Vite dashboard connected to FastAPI, SQLite local storage, PostgreSQL/pgvector Docker configuration, local Ollama generation, Temporal workflows, and Sentry spans. Configurations were treated as claims to verify, not proof of working features.

Agent

▸ python_environment_and_runtime_validation Compare the project Python environments, inspect API/board responses, build t...

Input

Compare the project Python environments, inspect API/board responses, build the frontend, and test local Ollama generation.

Output

The project Python 3.12 environment imports Pydantic 2 and pydantic-settings; a second Python 3.14 environment lacks Pydantic. Backend health and board endpoints responded, frontend production build passed, the Vite API proxy worked, and local Gemma generation returned a response.

Agent

▸ temporal_integration_validation Start the local Temporal dev server and exercise the worker with isolated tes...

Input

Start the local Temporal dev server and exercise the worker with isolated test data.

Output

Temporal workflow validation initially failed because the workflows package imported activities eagerly. Removing those import side effects allowed the worker to start. Workflow IDs were made unique, style retrieval now uses the stored thread body in both execution paths, and Temporal plus direct-fallback synthetic workflow tests passed.

Agent

▸ sentry_and_embedding_validation Verify content-safe Sentry telemetry and check the configured local embedding...

Input

Verify content-safe Sentry telemetry and check the configured local embedding path without transmitting email data.

Output

Sentry spans now record counts and error type rather than prompt/output previews; two focused tests passed. No live Sentry event was sent. Gemma generation works, but the configured embedding request returned HTTP 500, so the deterministic 384-dimensional fallback is non-semantic; this limitation is now logged and documented.

Agent

Backend unit tests and Python compilation passed. The browser rendered the three board columns without a fetch error. The active project Python environment is functional, but the Pylance environment report continued to show system Python 3.14 after an interpreter-switch request. The user authorized saving this sanitized session only; no DEV article draft, challenge submission, or external Sentry test event was authorized.

Session Summary: Contains complete prompt sequences, tool executions, and step-by-step refactoring logs recorded during development.

Architecture

+------------------------------------------------------+
|                React + Vite Dashboard                |
|    Needs Your Call | Week-Ahead Queue | Info/Closed  |
+----------------------------+-------------------------+
                             |
                         REST API
                             |
+----------------------------v-------------------------+
|                    FastAPI Backend                   |
+------------+-------------------+---------------------+
             |                   |
      +------v------+     +------v------+     +----------------+
      |  Temporal   |     | Local Gemma |     |   PostgreSQL   |
      |  Workflow   |<--->| via Ollama  |<--->|   + pgvector   |
      | & Activities|     |             |     |                |
      +------+------+     +-------------+     +----------------+
             |
      +------v-------------------------------------------+
      |             Sentry Observability                |
      |          Custom spans, latency, errors          |
      +--------------------------------------------------+

The key design principle is separation of concerns: Temporal coordinates long-running work, FastAPI exposes application functionality, Gemma handles language tasks, PostgreSQL stores persistent data, and Sentry helps diagnose failures.

Gemma: Triage and drafting

Gemma supports two main tasks:

Triage and extraction: Classifies emails, identifies urgency, extracts commitments, and suggests a target weekday.
Drafting with honest uncertainty: When an email requests information the system cannot verify—such as an hourly rate or meeting availability—it can flag the missing detail and route the message to Needs Your Call instead of guessing.

Temporal: Overnight orchestration

Local batch processing can be interrupted by inference delays, hardware limits, or other transient failures. Temporal's OvernightEmailPrepWorkflow coordinates the process through separate activities for parsing, semantic retrieval, extraction, and draft staging.

Configured retry policies help recover from transient failures, while controlled concurrency helps avoid exhausting local CPU or GPU resources.

Sentry: Observability

Sentry is used to help inspect inference and workflow behavior, including custom spans, execution latency, activity transitions, and Ollama HTTP errors. Token counts are tracked where available.

Tiger Data / pgvector: Semantic memory

PostgreSQL and pgvector provide a semantic retrieval layer. Relevant sent-email examples can help the system condition drafts on a user's preferred greetings, phrasing, and sign-offs.

Why Does Open Innovation Matter?

Email contains some of our most sensitive information: personal correspondence, financial documents, travel plans, health messages, and work commitments. Sending all of that content to a hosted AI API should not be the default.

Open-weight models and open-source infrastructure made a local-first architecture possible:

Local inference: Gemma runs through Ollama on the configured machine, so email content used for inference does not need to be sent to a third-party model API.
Fewer recurring costs: Local inference avoids per-token charges from hosted model APIs.
Data control: Users can keep imported emails and writing samples in their own environment, depending on their deployment and configuration.
Inspectable orchestration: Temporal workflows make the processing stages and retry behavior explicit.
Flexible infrastructure: PostgreSQL and pgvector provide a foundation for semantic retrieval without locking the project to a single proprietary AI platform.

This is not a claim that every deployment has zero network traffic. Privacy depends on the actual configuration, including telemetry, hosting, and any external integrations. The goal is to make local processing practical and keep private correspondence out of hosted model inference by design.

The Lazy Payoff

The point of ReplyLater is not to make people answer email faster every minute of the day. It is to reduce the number of decisions waiting for them when they sit down to work.

In a test run using 30 .eml messages, the observed results were:

Metric	Result
Total processed emails	30
Total batch execution time	3 min 48 sec
Average inference latency	2.82 seconds per message
Emails requiring replies	18
Messages routed to “Needs Your Call”	5
Receipts/digests auto-archived	7
External email-content egress during local inference	0 KB under the tested configuration

These are results from one test corpus, not a universal performance guarantee. The missing-information precision result should be interpreted in the context of the sample and labeling method.

The intended payoff is a calmer start to the week: fewer repetitive triage decisions, commitments surfaced before they are forgotten, and drafts ready for human review. ReplyLater stages drafts; it is not intended to send messages without the user's review.

Prize Categories

ReplyLater is intended for the following partner categories, based on the technologies used:

Gemma: Local open-weight language model for email triage, commitment extraction, and draft generation.
Temporal: Durable orchestration for overnight processing workflows.
Sentry: Observability and tracing for inference and workflow execution.
Tiger Data: PostgreSQL and pgvector-based semantic memory.

Please confirm these categories match the challenge's official eligibility and submission rules before publishing.

Final Thoughts

Technology shouldn't just accelerate how quickly we react; it should protect our attention and conserve our energy.

With open-weight models like Gemma, durable orchestration through Temporal, and observability from Sentry, ReplyLater explores a calmer way to handle the inbox: prepare the work while you rest, then let a human make the final call.

Shut your laptop. Get some sleep. Let ReplyLater prepare Monday morning.

I built a privacy-first AI cash-flow copilot for freelancers using Gemma 3 and Python

Avrojit Dutta — Sun, 18 Oct 2026 09:37:08 +0000

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

What I Built

Freelancers can be busy with client work and still have no clear idea how much money they will actually have next month.

An invoice might be issued today, but payment could arrive weeks late. Several delayed invoices can turn an otherwise profitable business into a cash flow problem. Spreadsheets help track what has happened, but spotting patterns, estimating future cash positions, and identifying unusual payment behaviour takes time.

That is the problem I wanted to tackle with CashFlowLens.

CashFlowLens is a cash flow analysis and forecasting tool designed for freelancers, independent consultants, and small agencies. The idea is simple: upload invoice or payment data in CSV format and turn it into information that helps you make better financial decisions.

The project focuses on three areas:

Cash flow forecasting: Use historical transaction data to help estimate what the coming weeks could look like.
Payment risk and anomaly analysis: Identify unusual payment patterns and potential delays that deserve attention.
AI-generated explanations: Make financial results easier to understand instead of presenting users with numbers they have to interpret themselves.

The potential paying customer is a freelancer or small agency that cannot justify expensive financial software but still needs better visibility into incoming payments.

I wanted to build something more useful than another dashboard full of charts. The goal is to help answer practical questions: Which payments deserve attention? What does the historical data suggest about upcoming cash flow? What should I investigate before a cash shortage becomes a problem?

CashFlowLens is still a work in progress, and I am actively working on making its forecasting and AI-assisted features reliable in the deployed environment.

Demo

Try the deployed application:

CashFlowLens Live Demo

The backend API and interactive documentation are also available:

The backend health endpoint is available at /health.

Current limitation: The application is deployed, but the AI briefing feature depends on an Ollama model service. A locally running Ollama instance is not automatically accessible from a cloud-hosted backend. I am working on a separate model-serving setup so the deployed application can use Gemma without depending on my personal computer being online.

I would rather be transparent about that limitation than present a partially working deployment as a finished product.

Code

The project is open source:

github.com/avrojitduttaj/CashFlowLens

The repository contains the frontend and backend implementation, including the API endpoints used for authentication, analytics uploads, payment-risk analysis, and AI-assisted explanations.

I would especially appreciate feedback on the forecasting approach, the handling of financial data, and how the results could become more useful to someone running a real freelance business.

How I Built It

CashFlowLens combines a conventional data-analysis pipeline with an open-weight language model.

The current stack includes:

React, TypeScript, and Vite for the frontend.
Python and FastAPI for the backend API.
Pandas for processing uploaded financial data.
scikit-learn for machine-learning workflows.
TabPFN for experimentation with tabular prediction and financial-data modelling.
Ollama and Gemma 3:4b for local open-weight language-model inference.
SQLite for lightweight account and application data storage.
Render for deployment.

One important design decision is to separate financial calculations from AI-generated explanations.

The numerical pipeline should be responsible for calculating metrics and analysing transaction records. The language model's role is to help explain those results in plain English. An AI-generated paragraph should not be treated as proof that a forecast is accurate, and it should never replace the underlying calculations.

I have also been experimenting with TabPFN because financial CSV data is tabular by nature. Rather than assuming that a general-purpose language model is the right tool for every task, I want to evaluate specialised models for structured prediction and anomaly detection.

There is still work to do here. Model selection, forecasting accuracy, validation against historical outcomes, and handling missing or inconsistent dates all matter more than simply adding an AI label to the application.

The biggest deployment lesson so far has been that running a model locally during development is not the same as making it available to a cloud application. My next step is to establish a secure, separately hosted Ollama service and connect it to the backend without exposing an unauthenticated model endpoint to the public internet.

Why Does Open Innovation Matter?

Financial data is sensitive. Freelancers may be uploading invoice amounts, payment dates, client identifiers, and other information they would not want casually shared with a third-party service.

That makes the choice of AI infrastructure important.

Using an open-weight model such as Gemma gives CashFlowLens more control over where inference happens, how the model is served, and which model is used. With Ollama, I can experiment with inference on my own machine instead of making every development request depend on a paid, closed-model API.

It also gives me room to compare models and control infrastructure costs as the project evolves. That matters for a tool aimed at people who may not have the budget for expensive subscriptions.

There is a distinction I want to preserve, though: using an open-weight model does not automatically make an application private. The deployment architecture, logging, data retention, access controls, and hosting provider still matter. CashFlowLens needs to make those choices deliberately.

Open tools have also made it practical for me to experiment with data-processing libraries, machine-learning models, and local inference without building everything from scratch or committing to a single proprietary AI provider.

For a small project, that flexibility is valuable. I can test an idea, inspect the implementation, replace a component, and learn from the results without having to redesign the entire application around one vendor.

The longer-term goal is to let users choose a deployment model that fits their needs: local inference for those who prioritise keeping data on their own machine, or a properly secured hosted inference service for those who need cloud access.

My Agent Session

I used AI-assisted development while building and debugging the project, including work on the backend, data-processing pipeline, and deployment issues.

I do not have a verified public DevRelay session link to include here, so I am leaving this section out rather than inventing one. If I publish a session that shows the actual development process, I can add it to this submission.

Prize Categories

The categories most relevant to CashFlowLens are:

Best Use of Gemma: Gemma 3:4b is the open-weight model used for AI-assisted financial explanations.
Best Use of TabPFN: TabPFN is being explored for prediction and analysis of structured financial data.
Best Use of Render: The frontend and backend are deployed on Render.

These are the categories the project is built to target; inclusion here is not a claim that the project has already won or fully satisfied every judging requirement.

What's Next?

I want CashFlowLens to become useful for an actual freelancer, not just look convincing in a demo.

The next priorities are:

Make the deployed AI briefing workflow reliable.
Test forecasts against historical data and report meaningful evaluation results.
Improve payment-delay and anomaly detection using realistic datasets.
Strengthen validation, authentication, and privacy protections.
Get feedback from freelancers or small-agency owners and use it to guide the next iteration.

If you manage your own freelance income, I would love to know what you currently use to track incoming payments, what you find frustrating about it, and whether a tool like this would be useful.

I built CashFlowLens because I think independent workers deserve better financial visibility without needing an expensive enterprise tool. Now I want to find out whether the idea holds up against real-world needs.

Repository: CashFlowLens on GitHub

Live demo: cashflowlens.onrender.com

devchallenge #hf26challenge #python #ai #opensource #webdev

What If AI Helped You Log Off and Go Outside?

Avrojit Dutta — Sun, 11 Oct 2026 07:17:17 +0000

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

GrassRoute: Using AI to Spend Less Time on Your Phone

What I Built

I wanted to build something that uses technology to get people away from technology.

Most of us spend a lot of time on our phones, even when we have some free time. Sometimes we want to go outside but end up scrolling because we do not know where to go or what to do.

That was the idea behind GrassRoute.

GrassRoute is an outdoor exploration app that helps people discover nearby green spaces, plan walking routes, and generate small missions based on the time they have.

You can choose between 15, 30, 45, and 60 minutes, select an exploration radius, and look for nearby outdoor places. The app can then help you plan a walk and generate a mission to make it a little more interesting.

The goal is not to keep people using another app for hours. It is to help them find something to do outside, get the information they need, and put their phones away.

Demo

Live website: https://grassroute-web1.onrender.com/

The frontend and backend are deployed on Render, so you can try the application online.

Code

GitHub repository: https://github.com/avrojitduttaj/GrassRoute

The repository contains the source code and setup instructions for running the project locally.

How I Built It

I built GrassRoute using React, Vite, TypeScript, Express, and Python.

Here is how the main parts fit together:

Frontend: React, Vite, TypeScript, Leaflet, and React-Leaflet power the interface and interactive map.
Backend: Express and TypeScript handle API requests, validate inputs, and connect the different services.
AI: I used Gemma 3 4B for the mission-generation feature. During local development, it can run through Ollama, with a Python FastAPI service handling requests. The deployed backend is configured to use Gemma through OpenRouter.
Place discovery: OpenStreetMap data and public Overpass API instances help find mapped parks, gardens, nature reserves, and other green spaces.
Walking routes: A Valhalla routing service provides walking route geometry, estimated distance, duration, and available directions.
Deployment: The frontend is deployed as a Render Static Site, while the backend runs as a separate Render Web Service.

One thing I wanted to account for was the possibility of the AI service failing. The app includes a fallback mission generator so that it can still return a basic mission when AI generation is unavailable.

Getting everything to work together took more effort than I initially expected. I had to fix TypeScript errors, deal with API integration problems, configure the deployment settings, and troubleshoot timeouts from public map-data services. There were several moments when something worked locally but needed more debugging after deployment.

Eventually, I got both services running online.

Why Does Open Innovation Matter?

I chose an open-weight model because I wanted to experiment with the AI instead of depending entirely on a closed model API.

With Gemma, I can change the prompts, experiment with different approaches to generating missions, and explore running the model locally through Ollama. This gives me more control over the AI component and makes local experimentation possible without depending on a hosted model endpoint.

For deployment, I chose a hosted inference option because running a model server continuously was not practical for my current setup.

There is an important distinction here: GrassRoute is not a completely offline application. The map, place discovery, and walking routes depend on internet services, and the deployed AI setup also uses a hosted endpoint.

Still, using an open-weight model gives me the flexibility to experiment locally and explore different ways of serving the model as the project develops.

I also wanted the application to remain useful when AI generation fails. A simple fallback mission is better than leaving the user with nothing because an external service is unavailable.

For me, open innovation is valuable because it gives developers room to understand, modify, and experiment with the technology they build on. It makes it easier to start small and improve a project without locking every part of it to one provider.

My Agent Session

I created a curated agent session for GrassRoute that summarizes the project and its development and deployment approach. The original IDE transcript was unavailable, so this is a curated build summary rather than a complete recording of the original development process.

GrassRoute: Building and Deploying an Open-Source AI Outdoor Companion

You

Prepare a curated build summary for GrassRoute. The original IDE development/deployment transcript was unavailable. Base the summary on the project brief and public repository documentation; do not fabricate tool calls or claim unobserved actions.

Agent

CURATED BUILD SUMMARY — ORIGINAL IDE DEVELOPMENT/DEPLOYMENT TRANSCRIPT UNAVAILABLE

GrassRoute grew from the “Touch Grass” idea: turn a nudge to spend less time on screens into an outdoor companion that helps someone choose a time, discover a nearby place, plan a walk, and take a small mission.

The project pairs a React, TypeScript, Vite, and React-Leaflet frontend with an Express/TypeScript API. It discovers outdoor places from OpenStreetMap via Overpass and requests pedestrian round-trip routes from Valhalla. The app can use browser geolocation after the user opts in, and the interface offers voice-friendly mission and route briefings.

For mission generation, the documented local-development setup uses a Python FastAPI service and the open-weight Gemma 3 4B model served by Ollama. If the AI service is unavailable, the backend can provide a deterministic fallback mission. Generated missions and public map/routing data have limitations and should not be treated as verified for feasibility, safety, accessibility, or current conditions.

The project brief identifies a Render deployment and debugging milestone. However, the original IDE transcript, Render logs, and deployment configuration were not available here, so this summary does not invent specific errors, fixes, commands, or deployment checks. The repository documentation describes local Ollama inference; the hosted demo’s inference provider and runtime path were not independently verified, and this session does not claim that hosted inference runs Ollama locally. GrassRoute is not fully offline: map tiles, place discovery, and route planning depend on internet services.

This is a curated summary based on the user’s project brief and the public repository README, not a record of observed build/deployment tool calls.

You can also view the GrassRoute Agent Session directly.

Prize Categories

Best Use of Gemma

GrassRoute uses Gemma 3 4B for its outdoor mission-generation feature, with local experimentation through Ollama and a hosted inference setup for deployment.

Best Use of Render

I deployed the frontend and backend as separate Render services, making the project available online without having to maintain my own server infrastructure.

What's Next?

GrassRoute is still an early-stage project, and there is a lot I would like to improve.

I want to make place discovery more reliable, improve mission personalization, and test the app during actual walks to see how useful the missions are in practice.

There are also limitations to account for. OpenStreetMap data may be incomplete, public services can experience downtime, and a mapped location or calculated route does not guarantee that a place is accessible, open, or safe.

I would like to keep improving the project based on how it performs outside a development environment.

Building GrassRoute for the Touch Grass theme gave me an opportunity to explore a different use of AI. Instead of using it to generate more content for someone to consume on a screen, I wanted to use it to help someone decide what to do after putting the screen away.

That is what I hope GrassRoute can do.

devchallenge #hf26challenge

HearthLore - Preserving the Recipes, Voices & Stories of Home

Avrojit Dutta — Sun, 04 Oct 2026 18:57:31 +0000

HearthLore: Preserving the Recipes, Voices, and Stories of Home

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

What I Built

HearthLore is an AI-powered family recipe and oral history preservation app built for the people in our lives whose best dishes exist only in memory, voice notes, and casual conversations rather than neat cookbooks.

Think of that one relative who explains a dish with phrases like:

"Bas thoda sa daalna hai... jab tak khushboo na aaye tab tak pakao."

Everyone at the table knows exactly what that tastes like, but nobody actually has the measurements written down. The instructions rely on intuition and aroma, and the stories tied to those meals risk being lost when the person who cooks them is no longer around.

HearthLore lets you record a family member talking through a recipe naturally in their own language. The application takes that spoken audio and handles the heavy lifting:

Transcribes the recording using Whisper
Detects the spoken language automatically
Interprets the raw transcript using Gemma
Extracts structured ingredients, measurements, and cooking steps
Preserves the verbatim original transcript alongside the parsed recipe
Stores everything in MongoDB Atlas so it stays accessible for the family

The aim is not simply running speech-to-text. It is about keeping a piece of family heritage intact.

Demo and Code

Live Frontend: https://hearthlore.onrender.com
GitHub Repository: https://github.com/avrojitduttaj/HearthLore

The frontend is live on Render. The AI pipeline runs locally for this demo, as Render's free tier has a 512 MB memory threshold that cannot comfortably load the Whisper and PyTorch runtime. The production backend can be hosted on a dedicated instance with sufficient RAM.

This is a solo project: I handled the design, pipeline architecture, API integration, and deployment.

How It Works

The data flows through a straightforward pipeline:

Voice Input: User records or uploads an audio clip of a family member explaining a dish.
Audio Processing: Whisper transcribes the speech and identifies the primary language.
Structured Extraction: Gemma analyzes the transcript via Ollama, separating actual kitchen steps from conversational banter.
Data Persistence: The parsed recipe, metadata, and original transcript are saved to MongoDB Atlas.
Presentation: The React interface displays the clean recipe side-by-side with the original transcript and audio context.

Tech Stack

Frontend: React, Vite, JavaScript, CSS
Backend: Python, FastAPI, Whisper, Ollama (Gemma)
Database: MongoDB Atlas
Hosting: Render

Open-Source AI and Why It Matters

Instead of routing personal recordings to a closed, third-party recipe generator, HearthLore relies on open-source AI tooling: Whisper for speech recognition and Gemma (via Ollama) for comprehension and extraction.

Family memories and personal voices are sensitive. Uploading intimate audio to a black-box commercial service felt counter to the spirit of the project. Using open models allowed me to keep data pipelines transparent, run inference locally, and tune prompts specifically around how families actually talk about food:

Understanding multi-lingual code-switching
Preserving approximate measurements instead of fabricating exact grams
Converting free-form narratives into step-by-step instructions
Distinguishing kitchen instructions from personal anecdotes without throwing the stories away
Acknowledging gaps when a detail was left unspoken, rather than hallucinating ingredients

Whisper provides the listening layer, Gemma provides the language understanding, and MongoDB Atlas provides the long-term memory.

Development Workflow

I developed HearthLore iteratively, pairing manual coding with AI-assisted debugging sessions to tune prompt constraints for Gemma, debug memory constraints during local audio transcription, and streamline the FastAPI endpoints.

Challenge Categories

Render (Best Use of Render): Deployed the frontend client and structured the repository for modular production hosting.
Gemma (Best Use of Gemma): Gemma powers the core extraction engine, converting messy spoken transcripts into reliable culinary steps without losing conversational context.
MongoDB Atlas: Serves as the primary operational database, keeping structured recipes, raw transcripts, and metadata indexed and queryable.

Author

Builder: Avrojit Dutta (Solo submission) DEV: @avrojitduttaj

Some of the most valuable culinary knowledge never makes it into print. It lives in someone's cadence, their memories, and their kitchen habits. HearthLore exists so those recipes and the voices behind them remain part of the family table for years to come.