DEV Community: Ghananil Shirpurkar

I Built MossMail

Ghananil Shirpurkar — Sun, 25 Oct 2026 13:48:54 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady. Built with Codex assistance. #devchallenge #hf26challenge

What I Built

An inbox tells us that something arrived. It rarely helps us decide whether that message deserves our attention right now.

I built MossMail, a local-first email triage prototype for people whose inbox keeps pulling them away from their work. Its promise is simple: a calmer inbox, less attention, better decisions.

MossMail makes waiting an explicit, reversible choice. Protected senders stay visible. Financial, legal, security, urgent, and deadline-sensitive messages go to review. Uncertain content and attachments also need a person. A low-risk subscription can be parked with a visible review deadline, and a follow-up brings its thread back.

Select a message to see its short summary or excerpt, suggested next step, and the actual rules behind its recommendation. You can keep it in review or mark it resolved. The product helps you decide where to look; it does not quietly delete mail.

The current release uses entirely fictional messages. It demonstrates the decision workflow without connecting to a live mailbox or sending, deleting, or archiving anything.

Demo

Try MossMail live →

No mailbox connection or model download is needed. Each visitor gets an isolated demo session. Try this small walkthrough:

Open the invoice and read the financial and deadline reasons keeping it visible.
Open Parked, then choose Simulate follow-up on a subscription.
Open Activity to inspect the escalation, or try Preview timer expiry to return a message for review.

The hosted app uses clearly labeled deterministic excerpts and simulated waiting controls. It does not run Gemma or a Temporal server in Community Cloud.

Watch the 107-second local Gemma demo to see actual local AI summaries. This genuine, silent browser recording uses the same fictional collection and explicitly labels its workflow simulation.

The separate durable Temporal implementation is exercised by real SDK integration tests and can be run using the server and worker commands in the README.

Code

MossMail on GitHub · MIT license · Validation

The repository includes the application, synthetic examples, tests, genuine captures, local setup instructions, and the Community Cloud entrypoint. Its policy and inference code are separate from the Streamlit interface, so the important behavior can be tested directly.

How I Built It

I used Python, Streamlit, Pydantic, SQLite, Ollama, and the Temporal Python SDK. Codex assisted with implementation, tests, documentation, and browser verification.

The inspiration was Khushighosh's Let It Die repository and its DEV article. I inspected the MIT-licensed repository before building. Local summaries and deferred-message workflows were the conceptual starting point.

MossMail independently implements a risk-first policy, review interface, structured summary boundary, MIME preparation, and transactional event ledger. No upstream source, dataset, predictions, caches, credentials, or Git history was copied. It also avoids treating a predicted lack of reply as proof that an email is unimportant.

Gemma helps with reading. The default model is configurable gemma3:4b; the actual local demonstration used the installed gemma2:2b through Ollama. Responses must match a JSON schema. Missing models, connection failures, uncertain parsing, and invalid output produce an honestly labeled excerpt. Email text is untrusted data, and the summarizer has no mailbox tools or policy authority.

Temporal makes waiting durable. A workflow records parking through an activity, waits for a timer or signal, and applies a safe local transition. Expiry returns a message for review. Activity retries are deduplicated, stale parking cycles cannot overwrite newer ones, and signals arriving during an in-flight expiry activity are processed before completion. Integration tests cover timers, signals, retry after commit, worker replacement, replay, and that signal race.

The cloud demo stays lightweight. A separate entrypoint isolates each visitor's synthetic state in a temporary database and bypasses Ollama. The local application retains its Gemma integration and persistent local state.

An optional hosted TabPFN adapter is implemented with explicit consent and numeric-only features. Hosted inference was not run for this submission, and no model-quality metric or TabPFN prize claim is made.

Why Does Open Innovation Matter?

Running Gemma locally lets the reading assistance work without sending message text to a hosted language-model provider. The model can be swapped through configuration, while the application remains usable if inference fails. Model weights are not bundled, and Gemma's own terms apply.

Temporal's open-source workflow tools make the waiting behavior inspectable and testable. I can reproduce a failure after a committed write, restart a worker, replay history, and check whether a follow-up still reaches the review queue.

The policy is readable Python. Someone can change protected senders, shorten the waiting period, or improve MIME handling while keeping those decisions visible. The useful open contribution is that whole boundary: code, examples, explanations, tests, and limitations.

My Agent Session

This project was built with Codex assistance. The implementation, validation notes, and commit history document the work. A public agent-session transcript is not included.

The Lazy Payoff

The intended payoff is fewer repeated decisions about low-risk messages: give them a deadline, let them wait, and return when there is new context or a reason to review.

The demo shows that behavior. Real-world time saved, changes in inbox-checking habits, and risk-detection accuracy have not been measured; those remain future evaluation work.

Prize Categories

Best Use of Gemma — actual local gemma2:2b inference through Ollama, demonstrated in the recorded application with model and source labels.
Best Use of Temporal — a durable workflow with activities, timers, signals, bounded retries, idempotent local effects, worker-recovery tests, and history replay.

The live Streamlit demo is a convenient way to explore the product. The local recording and integration tests provide the evidence for these two partner integrations. No other partner category is claimed.

PitchCraft Local — A Freelance Proposal Generator That Runs Locally

Ghananil Shirpurkar — Sat, 17 Oct 2026 10:21:00 +0000

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

What I Built

PitchCraft Local is a command-line tool that turns a client's brief into an editable freelance proposal with itemized pricing — powered by a local open-weight AI model.

Freelancers often spend time translating vague client requirements into a clear scope of work, estimating hours, calculating costs, and preparing professional proposals. PitchCraft Local helps streamline that process without requiring a paid AI subscription or cloud-based LLM API.

Here's what it does:

Generates proposals: Converts a client's brief into a structured scope of work, estimated hours, and project phases.
Calculates pricing independently: Uses deterministic Python calculations and decimal-based arithmetic instead of trusting the model to calculate money.
Supports editable output: Produces Markdown proposals alongside structured JSON for review and further processing.
Flags uncertainty: Highlights unknown services, missing information, and estimates that need human confirmation.
Keeps inference local: Uses Ollama with Qwen 2.5 3B, with no external inference API or application telemetry.

The target users are independent freelancers, solo developers, and small service businesses that repeatedly prepare project quotations.

The goal isn't to replace a freelancer's judgment. It's to reduce repetitive drafting and arithmetic so they can focus on scope clarification, realistic estimates, and client communication.

Demo

The repository includes screenshots of the CLI running locally, including model readiness checks, generated proposals, and tests.

The project runs from a terminal and is designed for resource-constrained hardware, including an Intel i3 machine with 8 GB RAM. CPU inference may be slow, depending on the brief and machine.

Code

GitHub repository: GhananilShirpurkar/pitchcraft-local

The project is written in Python and includes a CLI, configurable service catalogue, example client briefs, offline tests, and an evaluation runner.

Start with the repository README for installation instructions and a complete walkthrough.

How I Built It

I built PitchCraft Local around Python, Ollama, Qwen 2.5 3B, Pydantic, and deterministic pricing logic.

I deliberately chose a small local model because my development machine has an Intel i3 processor and 8 GB of RAM. Instead of relying on a large hosted model, I wanted to explore how useful a constrained, locally running model could be for a specific business workflow.

The pipeline looks like this:

Input: A client brief and the freelancer's configured service catalogue, rates, and terms.
Local inference: Qwen 2.5 3B drafts the project scope, estimates hours, and organizes the work.
Validation: Pydantic validates the proposal structure, while application logic checks catalogue references and flags unknown services.
Pricing: Python resolves the applicable rates and computes monetary amounts using Decimal arithmetic.
Output: The application generates Markdown and JSON files for the freelancer to review and edit.

A key design decision was to keep financial calculations outside the model. An LLM can help interpret a brief, but it shouldn't be trusted to perform authoritative pricing arithmetic.

I also added bounded inference attempts, offline tests, loopback-only runtime communication, and safeguards against treating client-provided text as trusted instructions.

The project is an MVP, not a production-ready commercial product. Its generated scope, estimates, and wording still require human review.

Why Does Open Innovation Matter?

Open innovation made it possible to experiment with an AI-powered business tool without depending on a proprietary inference API.

Using an open-weight model through Ollama gave me control over the runtime, the inference configuration, and how data moves through the application. It also let me build and test the workflow on modest hardware instead of designing around an expensive hosted model.

More importantly, this project explores a practical engineering question: How much of a useful AI product can be built with a small local model when the surrounding software is designed carefully?

The answer isn't that the model can do everything. It's that the model can handle language-heavy drafting while conventional code handles validation, pricing, file safety, and predictable business rules.

That separation makes the application easier to test, inspect, and improve.

One important caveat: the repository's MIT license covers the project code, not the model weights. The selected Qwen 2.5 3B model uses a separate Qwen Research License, which must be reviewed for the intended use.

My Agent Session

I haven't included a DevRelay agent-session link in this submission. The repository and its implementation are available above.

Prize Categories

Primary fit: Side Hustle — a practical tool aimed at helping freelancers reduce repetitive proposal preparation.

I Built ChronoDump: An AI That Turns Thought Dumps into Reminders

Ghananil Shirpurkar — Sat, 03 Oct 2026 17:02:49 +0000

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

What I Built

I built ChronoDump, a local-first AI Telegram bot for people who have a lot of thoughts, tasks, and deadlines but don't want to stop and organize them manually.

The idea came from a simple problem: sometimes you don't need another productivity app — you just need somewhere to dump your thoughts.

You can send ChronoDump a messy voice note or text such as:

“I need to finish chapter 4 tonight by 10, the report is due on 3rd January, remind me to drink water in two minutes, and I need to pick up my laundry sometime this weekend.”

ChronoDump transcribes and understands the dump, turns it into structured notes and action items, extracts deadlines, resolves time expressions, and automatically arms reminders.

When a time expression is ambiguous, it doesn't guess. Instead, it asks for clarification directly in Telegram.

The goal was to build something that feels like a small personal assistant rather than another task-management interface.

Demo

The working project is demonstrated through screenshots of the Telegram bot.

The screenshots show:

Voice note → structured notes
Extracted action items
Automatically armed reminders
Ambiguous-time clarification
Reminder notifications
+30m snooze
Marking reminders as done
Undo after completing a reminder
Direct text input

Code

GitHub: https://github.com/GhananilShirpurkar/ChronoDump

How I Built It

ChronoDump is built around local/open-weight AI rather than a closed cloud API.

The pipeline is:

Telegram → Whisper → Qwen3 → Pydantic → Temporal Engine → APScheduler → SQLite → Telegram

Stack

Python
aiogram 3 — Telegram bot framework
faster-whisper — local voice transcription
Qwen3 4B + Ollama — local language understanding
Pydantic v2 — structured model output
Python datetime + zoneinfo — deterministic time handling
APScheduler — reminder scheduling
SQLite — local persistence
SQLAlchemy — database access

The core design principle is:

LLM interprets. Python validates and reasons about time. APScheduler executes. SQLite remembers.

The LLM understands the user's intent, while deterministic Python code handles actual timestamps and scheduling. This prevents the model from directly deciding when a reminder should fire.

ChronoDump also includes a clarification flow for vague expressions such as “this weekend” or “later today” instead of silently making assumptions.

Why Does Open Innovation Matter?

ChronoDump is designed around the idea that useful AI doesn't always need to live behind a proprietary API.

Using open-weight models and local inference makes it possible to:

Keep personal voice notes and task data local
Avoid sending private dumps to a third-party AI provider
Run without relying on paid inference APIs
Swap models as better open models become available
Inspect and modify the AI pipeline
Self-host the entire system

For a tool that processes personal thoughts, reminders, deadlines, and voice notes, privacy and control are part of the product itself.

Open innovation made it possible to build this assistant using components that can be inspected, replaced, and self-hosted rather than locking the project to a single proprietary AI provider.

Prize Categories

Build for a Friend
Open-source AI / Open Innovation