DEV Community: Arpita Singh

I built Inbox Sloth: The Local-First AI Ghostwriter for Your Most Stressful Emails

Arpita Singh — Mon, 26 Oct 2026 06:52:50 +0000

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

What I Built

I built Inbox Sloth, a local-first AI ghostwriter that drafts emails in your exact voice.

We all have that one email we've been avoiding. The passive-aggressive client, the boss asking for a weekend update, the vendor asking for a meeting that could have been an email. Writing a reply takes 5 minutes. Avoiding it takes 3 days of low-grade anxiety.

ChatGPT doesn't fix this. It drafts generic corporate fluff that sounds like a robot.

Inbox Sloth fixes this. You paste the incoming email, and it generates three options:

Short: A 1-sentence reply.
Polite: A standard professional response.
Pushback: A firm decline.

But the magic is the Tone Profile. You can paste a past email you wrote. Inbox Sloth saves it to MongoDB Atlas. Next time you generate a reply, it uses MongoDB as a data layer to feed your past writing to the AI, so the drafts actually sound like you—not a customer service bot.

Demo

This app is designed to run 100% locally for privacy. The code is fully runnable via Ollama + MongoDB local.

Code

GITHUB URL

How I Built It

The stack is FastAPI, HTMX, MongoDB Atlas, and Gemma.

I wanted this to be zero-friction. There is no login, no file uploads, no complex UI. You paste text and hit a button. HTMX handles the asynchronous loading states without needing React.

The hardest part was the prompt engineering. To make the AI act as a ghostwriter, I fetch the user's past replies from MongoDB and inject them into the prompt as "Few-Shot Examples". Then, I force the AI to return a strict JSON object with exactly three keys (short, polite, pushback).

Because I used Gemma, I also had to add a custom parser to strip out the AI's "internal thoughts" before parsing the JSON, since Gemma sometimes tries to plan its response out loud.

Why Does Open Innovation Matter?

Emails contain sensitive company data, client names, and sometimes confidential legal discussions. Sending this data to a closed API like OpenAI means sending your company's inbox to a third-party server.

Inbox Sloth is local-first. If you run it with Ollama (gemma3:4b), your emails never leave your laptop. MongoDB can be run locally. The entire app is a private, closed loop.

To make the demo link work (since free hosting can't run a 4GB model), I built a hybrid architecture: it tries the local Ollama server first, and falls back to the Google AI Studio API only if needed. The app remains 100% open-source and can be run completely offline.

Prize Categories

Best Use of MongoDB Atlas — Used as the persistent data layer to store and retrieve the user's Tone Profile for few-shot prompting.
Best Use of Gemma — Gemma 3 4B via local Ollama, with a Google AI Studio Gemma fallback.
Best Use of Render — FastAPI app designed for Render deployment using the cloud inference fallback.

I Built Rehearse to Sell A Voice-First, Local-First AI Interview Coach

Arpita Singh — Sun, 18 Oct 2026 10:29:10 +0000

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

What I Built

I built Rehearse, a voice-first and local-first AI interviewer.

You know how you read a list of "Top 50 Interview Questions," think "I could answer that," and then completely freeze when you actually have to speak out loud? That is the exact problem this solves.

ChatGPT doesn't help here. If you ask it to practice with you, it gives you a giant essay, says "Great job!", and never pushes back. A real interview is a conversation. Rehearse actually talks to you (using voice), cuts you off if you ramble, and forces you to answer the hard follow-up questions. At the end, it grades you out of 10 and tells you how a better candidate would have answered.

I didn't want this to just be for software engineers. You can type "Marketing," "Nursing," or "Sales," and the AI changes its tone and questions to match that field. And if you pick "Stress Test" mode, it acts like a genuinely hostile interviewer.

Demo

Deployed Render URL

Code

GitHub Repository Link

How I Built It

The stack is FastAPI, HTMX, and Gemma. I used the browser's built-in microphone and text-to-speech so it works instantly without saving audio files to a server.

The hardest part wasn't the code, it was stopping the AI from being too nice. I had to write a very strict set of rules for the prompt. It is explicitly banned from saying things like "Great answer" or "I understand." If you say "we built a system," it is instructed to interrupt you and ask, "What did you specifically do?"

I also ran into a hilarious bug. Gemma on Google's API is a "thinking" model. Instead of just asking the question, it would write out its entire internal thought process: "Wait, the prompt says no meta-text. Let's try asking this..."

Because my app reads the text out loud, it was literally speaking the AI's internal self-doubt to the user. I had to write a Python script that scans the AI's output bottom-up, ignores the monologue, and grabs only the final question.

Why Does Open Innovation Matter?

Interviewing is vulnerable. You are anxious, alone, and talking to a screen. If this used a closed API, it would mean sending your awkward voice recordings to a giant tech company's server.

Because it uses open-source AI, this app can run 100% locally. If you run it with Ollama, nothing leaves your laptop.

To make the app demoable as a live link (since free hosting can't run a 4GB model), I built a fallback: it tries the local Ollama server first, and if you don't have it running, it uses the Google API. This local-first setup is only possible because open models are finally small enough to run on normal laptops.

My First User

I tested this on a friend preparing for MBA interviews.

She typed in a real consulting job description. Her first answer was a rambling 3-minute story about a college project. The AI instantly interrupted her (in voice) and asked, "You mentioned an increase in engagement. What was the specific metric before and after?" She froze, laughed, and said, "Wow, this is actually stressful."

Would she pay for it? She said she wouldn't pay monthly, but she would happily pay $5 for a "7-day sprint" pass right before placement season.

What did she ask for next? She wanted to upload her resume so the AI could ask questions about her specific internships. (Adding that to the roadmap for improvement).

Prize Categories

Best Use of Gemma — Gemma 3 4B via local Ollama, with a Google AI Studio Gemma fallback.
Best Use of Render — FastAPI app deployed on Render using the cloud inference fallback.

I built Greenstep – An Open-Source App That Picks Your Next Walk

Arpita Singh — Mon, 12 Oct 2026 06:29:04 +0000

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

What I Built

I built Greenstep, an app that tells you when to go outside — not just that you should.

Most "touch grass" tools work the same way: they tell you to take a break, go for a walk, get some fresh air. The advice is correct and useless. You already know you should go outside. The hard part is that at 6 PM, after a full day, there's no clear signal that this is the moment, and no specific place to go, and no reason to believe the walk will feel good. So you don't go.

Greenstep attacks all three problems at once:

When — a tabular foundation model (TabPFN) reads a small log of your past outdoor behavior — sleep, screen time, mood, weather, which evening hours you actually went out — and predicts the single best 30-minute window for today.
Where — SerpApi fetches a real, verified place near you: a park, a cafe, a walking loop. Not "a park nearby." A named place with a distance.
What — Gemma 3 writes one specific, startable action for that window and place, with a first step and a fallback.

The output is short and finishable. Something like:

Walk through Lodhi Garden in Delhi. 25 minutes.
The mild evening temperature and your energy level suit a low-intensity stroll.
First step: put on your walking shoes.
Fallback: sit on a bench outside.

It's for anyone who knows they'd feel better after a walk, but needs the decision made for them. The whole thing runs on open models and is designed to sit on a second monitor, not beg for attention.

Demo

Code

How I Built It

Stack: FastAPI + Jinja + HTMX, SQLite for local history, and a three-model pipeline:

TabPFN (Prior Labs) — reads a 150-row CSV of past behavior and predicts today's best hour. This is the part that makes it different: TabPFN is a tabular foundation model, not a language model. It's built for exactly this — small structured data, fast classification, no training loop.
SerpApi — Google Maps search for places matching the predicted window (parks in the afternoon, cafes in the evening).
Gemma 3 4B — runs locally through Ollama during development, and falls back to Google AI Studio's Gemma endpoint when deployed, so the whole thing can be tried without installing anything.

The inference layer is a single module (ai_provider.py) that switches between local and cloud with one environment variable:


AI_PROVIDER=local   # Ollama + gemma3:4b on your machine
AI_PROVIDER=api     # Gemma via Google AI Studio

Same prompt, same output schema, same code path. The only difference is the base URL. That means the app is honest about being local-first, and still demo-able as a link.

Gemma on the Gemini API has three quirks worth documenting because they cost me most of a day:

It doesn't accept system_instruction. Instructions have to live in the user message.
It doesn't accept responseMimeType: "application/json". There is no JSON mode. The prompt has to enforce the format, and the parser has to be forgiving.
It doesn't accept thinkingConfig, even though the model metadata reports thinking: true.

The parser (_parse_json) strips markdown fences, cuts preamble before the first {, and cuts trailing text after the last }. That's what makes a small open model usable for a structured output app.

Why Does Open Innovation Matter?

Greenstep reads things most people would not want to hand to a third party: when you sleep, how much you scroll, how you felt each day, whether you left the house. A closed API version of this would mean shipping a behavioral diary to a vendor, paying per prediction, and hoping the model doesn't drift on them in six months.

Running Gemma locally changes what's possible:

The history stays on the machine. The CSV never leaves. Neither does the inference.
The deployed version uses the same open model. It's Gemma on Google AI Studio, not a closed replacement. One env var switches the runtime, not the model family.
The prompt is auditable. You can read exactly what the app sends. With a closed API, that's a black box you trust.
Swapping is trivial. When a better small model ships, the change is one line.

This is what open models enable: an app that can be personal without being creepy, local without being crippled, and specific without being expensive.

Prize Categories

Best Use of Gemma — Gemma 3 4B via Ollama (local) and Gemma via Google AI Studio (deployed)
Best Use of TabPFN — predicting the best outdoor window from a small behavioral CSV
Best Use of SerpApi — grounding the suggestion in a real, named place nearby
Best Use of Render — deployed FastAPI app with the Gemma cloud fallback

What Now? – A Local-First AI Next-Action Coach for a Tired College Student

Arpita Singh — Mon, 05 Oct 2026 06:58:30 +0000

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

What I Built

I built What Now? for a friend of mine. She's 20, in her second year of CS, and she has the kind of schedule that looks fine on paper and falls apart by evening.

Here's what I kept noticing. She isn't confused about what matters. She has a DBMS assignment due tomorrow, placement prep she's behind on, a gym membership she pays for and doesn't use, and a real need to rest. She knows all of it. But at 7:30 PM, after a full day of college, the gap between knowing and starting is where the evening goes. One reel becomes ten. "I'll start after this episode" becomes three. The assignment stays open in a tab she doesn't touch.

It isn't laziness. Deciding what to start takes more energy than starting it.

What she needed wasn't another planner. She's tried those. They hand her a list of twelve things and call it clarity, which is the same problem wearing a nicer font. What she needed was for something else to make the call. One thing. Right now. Small enough that saying yes doesn't feel like a commitment.

That's what I built. A loop, not an app. She opens it, sets her energy on a 1–5 slider, says how many minutes she has, and hits one button. The app pulls her active tasks, sends the context to a language model running locally, and gets back a single action:

Open the DBMS assignment PDF and write the first SQL query for Q1.
Why: due tomorrow at 9 AM, high urgency.
First step: open the PDF. Timebox: 15 minutes.
Fallback: if still low energy, review one DSA problem instead.

That's the whole output. No list. No options. No priority matrix asking her to rank things she's too tired to rank.

The flow, end to end:

She adds her tasks once, whenever she has the energy to think about them. Title, deadline, roughly how long it'll take, how much energy it costs, and how much it matters.
Later that evening, she opens the app. Nothing to re-enter. Her tasks are already there.
She sets energy to 2 and minutes to 45. The check-in form is the first thing on the page, because that's the only decision I want her making at 7:30 PM.
The app sends her context to Gemma 3 4B, running locally through Ollama, and gets back one action with a reason, a two-minute first step, a timebox, and a fallback.
The action card appears below the form. She reads it, and either starts or she doesn't.
Either way, she taps Done, Skip, or Blocked. The outcome gets logged, so the app builds up a history of what actually got done versus what got suggested.
Next time she checks in, the loop runs again.

The goal was never to turn her into a productivity machine. She can still watch her shows and play guitar. The goal was to close the gap between knowing and starting.

Demo

Local-first, so there's no hosted URL, the app runs on her laptop alongside Ollama.

Code

GITHUB

How I Built It

Stack: FastAPI with HTMX on the front end, SQLite for storage, and Gemma 3 4B running locally through Ollama.

Four files carry the project:

prompts.py holds the system prompt. It tells the model to return strict JSON with five fields: action, why, first_step, timebox_minutes, fallback.
agent.py calls Ollama's /api/generate endpoint with format: "json", which constrains output to valid JSON at the sampler level. No markdown fences, no "Sure, here's your answer."
db.py stores tasks and logs every action with its outcome.
main.py wires the routes and swaps HTML fragments with HTMX.

The prompt does most of the heavy lifting. It tells the model to pick exactly one task, to respect energy levels (if energy is 2 or below, no high-energy tasks unless the deadline is under 24 hours), to keep timeboxes under 25 minutes, and to write like a peer rather than a coach. No "let's crush it" or "you got this." The model isn't doing anything clever here. The context carries the thinking. The model just picks and phrases.

Swapping models is one environment variable:
WHATNOW_MODEL=qwen2.5:7b uv run uvicorn src.what_now.main:app

I went with Ollama over the alternatives because it handles quantization, memory, and model downloads without me writing any of that myself. It exposes a plain HTTP endpoint, so the Python side is a single httpx call. Nothing about the app is tied to Gemma specifically. The prompt, the schema, and the check-in flow all work with any instruction-following model you can run locally.

Why Does Open Innovation Matter?

Her task list contains her exam schedule, her placement prep, and goals she hasn't shared with anyone. A closed API would mean sending that to a server, paying per call, and trusting a vendor's logs.

Running Gemma locally through Ollama means:

Nothing leaves her laptop.
No API bills and no rate limits.
Every prompt is in the repo. She can read exactly what the model sees.
When a better open model comes out, she swaps one environment variable.

That last one is the part I keep coming back to. If I'd built this on a closed API, the project would be a wrapper around someone else's product, and it would stop working the day they change their pricing or deprecate the model. Because the model runs on her machine, it's hers. She can read it, change it, or replace it without asking anyone.

Prize Categories

Best Use of Gemma

Introduction to Object-Oriented Programming (OOP)

Arpita Singh — Fri, 02 Oct 2026 18:38:53 +0000

Object-Oriented Programming (OOP) is a programming paradigm centered around structuring code into self-contained units called objects. Instead of storing related data across separate, disconnected arrays, OOP bundles data and actions together to model real-world entities cleanly.

Key Building Blocks:

i) Class: The structural blueprint or template (e.g., User or BankAccount). It defines what fields and methods its instances will have.

ii) Object: A concrete instance created from a class residing in memory (e.g., user1).

iii) State (Fields): The data or properties an object holds, such as email, balance, or status.

iv) Behavior (Methods): The actions an object can perform, such as login(), deposit(), or withdraw().

The 4 Core Pillars:

i) Encapsulation: Hides internal data using private fields and exposes controlled access via getters and setters to protect data integrity.

ii) Abstraction: Exposes essential features while hiding underlying implementation details using abstract classes and interfaces.

iii) Inheritance: Enables child classes to reuse properties and methods from a parent class via extends.

iv) Polymorphism: Allows methods to execute differently based on the object invoking them, through method overloading and dynamic overriding.

By enforcing separation of concerns, OOP prevents silent data corruption, eliminates synchronization bugs, and makes large software applications modular, scalable, and easy to maintain.