DEV Community: BHAVYA GOTHI

Circular Sloth: The School WhatsApp Notices Your Brain Never Has to Read Twice Short, clear, and says exactly who it’s for.

BHAVYA GOTHI — Thu, 22 Oct 2026 04:19:15 +0000

What I Built

School circulars arrive in WhatsApp in English, Hindi, and Marathi, often mixed in with everything else. A deadline can get buried, and the consequence can be as small—and as stressful—as sending a child in the wrong shoes.
Circular Sloth turns a circular into a reviewable list for parents of school-going kids. It can:

Accept text shared from WhatsApp, pasted messages, photos, and PDFs.
Read the circular and suggest only the actions, dates, amounts, and things to bring or wear that matter.
Let a parent review and edit those suggestions before saving them.
Show a Tomorrow checklist and a printable/shareable Weekly Slip.
Export calendar reminders and draft a reply to a teacher in WhatsApp. The honest lazy claim is: “One tap in WhatsApp, then zero effort.” That is the aspiration after sharing, not a claim of full automation: OCR and model suggestions can be wrong, and a parent must review them.

Demo

Live Now:-

circular-sloth.onrender.com

Tap “Try a sample circular” on Tomorrow to send sample text to the real model; there is no canned response. The free-tier model can briefly be busy; the API retries temporary provider errors.

Write or copy paste whatsapp message

Upload a circular

List of tomorrow's reminders

Review the extracted suggestions and check the important details before saving.

The week’s dates and tasks, ready to print or share.

Code

Bhavya4523 / circular-sloth

Circular Sloth

Circular Sloth turns school circulars into a short, reviewable list of what a parent needs to do. Add a pasted message, photo, PDF, or shared item; extract text; review and edit suggestions; then save the items to the browser's local workspace. It also includes a weekly fridge slip, calendar export, summary, and reply drafting.

The project uses open-weight language models through OpenRouter or a compatible hosted endpoint, and can use Ollama locally. A model can make mistakes: parents must check every extracted item before saving or acting on it.

Privacy and ownership

Family records are stored in IndexedDB in the browser profile. The server has no accounts, database, cookies, or family-record storage.
Photos and PDFs are processed in the browser; the app sends extracted text to the API when model assistance is requested. In hosted mode that text is sent to the configured model provider. The provider's retention…

View on GitHub

The repo contains the React app, FastAPI service, tests, evaluation notes, and Render configuration. DEV profile: [Bhavya4523].

How I Built It

The hosted app uses Gemma 4, an open-weight model served through OpenRouter’s OpenAI-compatible API. Environment variables switch the provider and model. Ollama with Gemma 3 (gemma3:4b) is the local option. The localhost smoke passed, but internet remained on, so this was not a fully isolated offline test.

Architecture: Browser (local records + OCR/PDF extraction) → stateless FastAPI → configured hosted provider or local Ollama → reviewed suggestions in the browser.
The backend keeps no family records. Hosted mode sends extracted text—not photos—from the browser through the API to the provider. Parents review suggestions before saving. The API retries temporary 429/5xx provider errors and reports when the reader is busy. Its smoke test adds a fresh random rupee amount and future date to a request and only passes if the response contains that injected pair exactly once. The README records a passing Render smoke with Rs 285 and 2027-05-01.
Render’s Docker build initially failed because the Dockerfile copied a missing web/build.mjs. I fixed the frontend build stage and the corrected deployment succeeded. A local Docker build remains unverified because Docker Desktop returned an internal Linux-engine API error.

Why Does Open Innovation Matter?

School and class details are sensitive. Circular Sloth keeps family records in the browser and avoids sending a child’s name in model requests. The model provider can be changed through configuration, and the same API code supports local Ollama, so the app is not tied to one hosted model service.

Honest trade-off

The live demo sends circular text, never photos, to OpenRouter and the company hosting the model. Their retention and privacy policies apply. For a stronger privacy boundary, use the local Ollama path; the README’s smoke passed against localhost, but internet access was still on during that check.

Where open beat closed

In this project, an open-weight Gemma model could be served through OpenRouter for the live app and swapped for Ollama locally using configuration. That gave me one model interface for hosted and local experiments without changing the app’s core request flow. In the README evaluation, the free provider returned 29 errors across 30 synthetic notices, so its low score is not a useful model-quality estimate.

The Lazy Payoff

Manual estimate, not a measurement: reading a circular, finding its deadline, and copying dates might take a few minutes, depending on its length. With Circular Sloth, a parent shares or adds it, checks the suggested details, and saves the ones that are right. Review still takes time; the goal is less hunting through chats and retyping dates.

Prize Categories

Gemma: Gemma 4 is the open-weight model configured for hosted requests through OpenRouter; Gemma 3 (gemma3:4b) was used for the local Ollama smoke test.
Render: The live Circular Sloth app is hosted at Render, with its deployment configuration in the repository.

_
Small steps, fewer missed circulars, and a little more breathing room for busy parents._

Pakka Khata — A Smarter Digital Khata for Small Indian Shops

BHAVYA GOTHI — Fri, 16 Oct 2026 11:48:00 +0000

What I Built

Pakka Khata is a digital ledger designed for small Indian shopkeepers who still rely on handwritten khata books to track customer credit, payments, and outstanding balances.

These notebooks are familiar, but searching old transactions, calculating dues, preserving records, and reminding customers to pay can be tedious. Pakka Khata brings this everyday workflow into a simple digital application, using open-source AI to help digitize handwritten records.

What it can do

AI-assisted ledger scanning: Turn a photograph of a handwritten ledger page into structured transaction rows.
Human-reviewed extraction: Review and correct extracted details before saving them.
Customer-wise bookkeeping: Manage customers, transaction histories, payments, and outstanding balances.
Multilingual reminders: Prepare payment reminders in English, Hindi, Marathi, and Hinglish, ready to copy or share through WhatsApp.
Local-first data storage: Keep customer and ledger records in the browser rather than a central application database.
Data portability: Support encrypted backups, restoration, and CSV export.
The idea is simple: help shopkeepers spend less time maintaining their books without forcing them to abandon a familiar way of working.

Demo

pakka-khata.onrender.com

The deployed application lets users explore the interface and ledger workflows.

Important transparency note: The hosted version currently runs with demo-mode scanning, which returns clearly labelled sample extraction results rather than performing real model inference on the uploaded photograph. Actual model-based scanning has been tested locally with Ollama and Gemma 3 4B. The live demo and local AI configuration are documented in the repository.

Code

GitHub:

Bhavya4523 / pakka-khata-

Pakka Khata — Local-first digital khata for small Indian shops

Pakka Khata is a private digital khata book for small Indian shops. It is designed to read a photo of a handwritten ledger page into a reviewable set of rows, then draft a polite payment reminder in the customer's language.

Current status

Phase 1 provides the stateless FastAPI service, image validation and in-memory multipart processing, Ollama/OpenAI-compatible provider adapter for open-weight models, extraction validation and retry/repair, reminder drafting, demo mode, security headers, Docker/Render deployment foundation, and API tests. Phase 2 adds the multilingual React/Vite ledger shell, Dexie/IndexedDB browser storage, shop setup, summary dashboard, sample ledger, App Lock, encrypted backup/restore, CSV export, deletion, and PWA offline app shell. Phase 3 connects photo scanning and review to the API, then adds editable ledger rows, customer management, manual entries and payments, and WhatsApp-ready reminder drafts. Phase 4 adds labelled-image evaluation tooling, accessibility/security release checklists…

View on GitHub

The repository contains the frontend, FastAPI backend, tests, Docker configuration, deployment setup, and installation guides for the different development phases.

The project is designed so that the backend does not maintain a central database of customers or ledger transactions. The browser owns the ledger data, while the backend processes scan and reminder requests.

How I Built It

TECHSTACK

Frontend: React, Vite, TypeScript
Browser Storage: IndexedDB and Dexie
Backend: Python, FastAPI, Pydantic
AI: Gemma 3 4B through Ollama for local model inference
Deployment: Docker, Docker Compose, Render
Testing: Vitest, pytest ###How the AI works

Pakka Khata uses Gemma 3 4B, an open-weight multimodal model, through Ollama for local inference.

The model helps interpret a handwritten ledger image and extract structured information. The application then presents the result for human review instead of automatically trusting every extracted amount or customer name.

The frontend stores ledger records in browser-local IndexedDB. This separates the shopkeeper's ledger storage from the backend's image-processing workflow.

The application was tested across frontend and backend suites, with 12 frontend tests and 31 backend tests passing. Core workflows were also checked manually, including ledger review, saving records, customer management, persistence after refresh, and payment reminders.

Architecture and Implementation

The frontend stores shop settings, customers, and ledger entries locally using Dexie and IndexedDB. When a user scans a ledger page, the image is processed and sent to the backend for extraction. The resulting rows are presented for correction and confirmation before being saved to the local ledger.
The local inference setup uses Ollama with Gemma 3 4B. Docker Compose brings the application and model service together for local development.
The project also includes validation, error handling, request limits, security-conscious logging, and a clearly labelled demo mode for deployment without a dedicated model server.

Testing

The project was tested incrementally across frontend and backend components. The frontend test suite passed 12 tests across four test files, and the backend test suite passed 31 tests. The production frontend build also completed successfully.
Manual end-to-end checks covered scanning and reviewing records, saving entries, managing customer ledgers, persistence after refresh, recording payments, and preparing reminders.

Why Does Open Innovation Matter?

For Pakka Khata, open innovation is not just a technology choice. It shapes how the product can work for small businesses.

Privacy and control: Running Gemma locally through Ollama allows ledger images to be processed without sending them to a third-party hosted AI provider. This is valuable when records contain customer names, credit amounts, and payment histories.

Cost control: Local inference avoids per-request charges from a hosted AI API, although it still requires suitable hardware and electricity. That creates a potential path towards sustainable operating costs for a small-business product.

Freedom to experiment: Using an open-weight model gives developers greater flexibility to inspect the workflow, modify prompts, and experiment with alternative models instead of being tied to one provider's API and pricing.

A practical use case: Rather than building another generic AI chatbot, Pakka Khata applies open-source AI to a specific task that small retailers may genuinely need help with.

The local-first approach is a promising foundation, although it does not yet mean the hosted deployment provides the same live AI functionality.

My Agent Session

The project was developed through an iterative workflow involving implementation, debugging, testing, local AI integration, Docker validation, and deployment.

Repository and implementation: https://github.com/Bhavya4523/pakka-khata-

If the submission form specifically requires a shareable agent-session transcript, add that session's URL here. The repository link is provided separately as the source-code reference.

My First User

My first user was the owner of a small kirana shop in my neighbourhood, where I regularly buy groceries.

I approached him with Pakka Khata and let him use the locally running version on my laptop for a day. I wanted to see whether the application would be useful in an actual shopkeeping context, not just whether it worked during development.

He was impressed by the idea and found the application helpful for digitising handwritten ledger records and managing customer transactions. It was encouraging to see someone outside my development process understand the problem it was trying to solve.

To be transparent, I provided the local version because the deployed version currently uses sample extraction results. The local version uses Ollama and Gemma 3 4B for actual model inference.

This was an initial, one-day trial with one shopkeeper, not a large-scale user study. He did not pay for the application, so I have not yet validated willingness to pay.

The experience reinforced my belief that a focused, familiar tool could be useful to small retailers. My next step would be to gather more feedback, improve the deployed AI experience, and understand which features shopkeepers would value enough to pay for.

Prize Categories

Project theme: SIDE HUSTLE
Pakka Khata explores the potential for a small, practical software product built around an everyday business problem.

The target users are kirana shopkeepers who want to maintain customer credit records without spending extra time manually digitising their notebooks. A future sustainable version could offer a straightforward bookkeeping workflow, privacy-conscious AI scanning, and convenient payment reminders.

The first shopkeeper trial gave me an initial signal of usefulness, but it is only a starting point. Pricing, repeat usage, willingness to pay, and broader demand still need to be validated.

I built Pakka Khata to explore how open-source AI can help turn a familiar manual task into a more manageable digital workflow.

Pakka Khata — helping small shops keep their trusted khata, with a smarter way to manage it.

SIDEQUEST: Your Destination Isn't the Point

BHAVYA GOTHI — Thu, 08 Oct 2026 14:55:41 +0000

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

🌱 What I Built

Most apps are designed to make journeys more efficient.

SIDEQUEST is designed to make the journey itself worth noticing.

You already have somewhere to go.

Your college.
Your train station.
Your home.
A friend's place.

SIDEQUEST takes that ordinary journey and turns it into a tiny real-world adventure.

You tell it:

where you're going
how much time you have
how you're feeling
what interests you

Then the AI gives you one small mission that fits the journey.

Not a travel itinerary.

Not a list of places.

Not another feed to scroll.

A sidequest.

For example:

Find one detail on your route that you've probably walked past before.

Or:

Take the quieter street and notice three different textures on the buildings around you.

Or:

Find a local food smell you wouldn't normally follow and discover where it comes from.

The important part comes after the AI finishes.

You put the phone down.

The intended loop is:

PLAN → GET QUEST → LEAVE PHONE → EXPERIENCE WORLD → RETURN → REFLECT

That is the product philosophy behind SIDEQUEST:

The best outcome is not more screen time.

The best outcome is that you stop using the app.

SIDEQUEST is built for people who already have somewhere to be, but don't want to sleepwalk through the journey.

What makes it different?

The AI isn't the destination.

It's the excuse to go outside.

SIDEQUEST combines:

personalized quest generation
multiple AI-generated candidates
deterministic quest ranking
safety filtering
anti-repetition checks
feedback-based personalization
a field journal
exploration statistics
Chaos Mode for unplanned adventures
local AI support through Ollama

And the entire UI is built around one idea:

make the screen useful for a few seconds, then get out of the way.

🎥 Demo

Try SIDEQUEST

sidequest-jstk.onrender.com

The public demo lets you:

Enter your destination
Choose your available time
Pick your mood
Choose your interests
Generate a SIDEQUEST
Put your phone down
Complete the real-world mission
Return and reflect

The local version goes one step further: Gemma can run through Ollama directly on the laptop, so the core generation path can work without internet access.

💻 Code

Bhavya4523 / SIDEQUEST

The repository contains the frontend, FastAPI backend, AI generation pipeline, safety filtering, ranking logic, personalization system, SQLite database layer, and local Ollama integration.

⚙️ How I Built It

Step 1: Start with the real problem, not the AI

I didn't start by asking:

"What can I do with an LLM?"

I started with:

"What if an app was successful when you stopped looking at it?"

Most digital products optimize for engagement.

SIDEQUEST deliberately optimizes for departure.

That constraint shaped the architecture, the UI, and even the way the AI generates quests.

Step 2: Make the AI generate experiences, not recommendations

A normal recommendation system might return:

"Visit this cafe."

That's not what SIDEQUEST is trying to do.

The AI receives structured journey context:

destination + available time + mood + interests

and turns it into a small actionable experience.

The output follows a structured quest format containing things like:

title
duration
difficulty
category
objective
steps
novelty score
safety notes

This gives the rest of the system something predictable to validate and rank instead of blindly displaying raw model output.

Step 3: Generate candidates, then choose

One of the important design decisions was not accepting the first AI answer.

SIDEQUEST generates multiple candidate quests.

Those candidates then move through a pipeline:


Journey Context
      ↓
Context Builder
      ↓
Open-Weight AI
      ↓
Candidate Quests
      ↓
Validation
      ↓
Safety Filter
      ↓
Anti-Repetition Check
      ↓
Quest Ranking
      ↓
Final SIDEQUEST

The ranking layer considers factors such as:

time fit
personalization
novelty
feasibility
historical preference
recent repetition So the LLM proposes possibilities. The application decides which one makes the most sense.

Step 4: Don't let the model decide what's safe

An AI-generated activity can sound harmless while still being a bad idea in the real world.
SIDEQUEST therefore has a separate safety filtering layer.
Generated quests are screened for things such as:

unsafe roads
dangerous activities
trespassing or private property
unsafe wildlife interaction
phone-dependent activities
other inappropriate instructions The important architectural choice is that safety isn't left entirely to the model. The model generates. The application validates.

Step 5: Make repetition harder

A generative model can produce ten different sentences that all describe the same experience.
That becomes annoying very quickly.
So SIDEQUEST keeps track of previous quests and checks new candidates for semantic similarity.
If a new quest is too close to recent experiences, it can be rejected and regenerated.
Recent category usage also affects ranking so the system has an incentive to vary the type of experience.
The goal is:
Not another quest.
A different experience.

Step 6: Let the system learn from the person

Personalization shouldn't mean asking users to fill out a giant profile.
SIDEQUEST learns from what happens after the quest.
When you return, you can say:

completed
partly completed
skipped You can also give a rating and write a reflection. That feedback updates a lightweight personalization profile. Over time, the system can learn things such as:
which categories the user tends to enjoy
preferred difficulty
preferred duration
how much novelty they respond to

So the loop becomes:

GENERATE
↓
EXPERIENCE
↓
REFLECT
↓
LEARN
↓
GENERATE BETTER

Step 7: Chaos Mode

Sometimes planning is exactly what gets in the way.
So SIDEQUEST has Chaos Mode.
Instead of carefully specifying the journey context, the user can simply give the available time and let the system create an unexpected adventure.
It's the same core idea with less planning:
You don't need a reason to explore.
You just need a little time.

Step 8: Local-first AI

The local version of SIDEQUEST runs:

React
   ↓
FastAPI
   ↓
Ollama
   ↓
Gemma 3 4B
   ↓
SQLite

Gemma 3 4B runs locally through Ollama.
That means the local application can generate quests on the same machine without depending on a remote AI API.
This was especially important for SIDEQUEST because the application deals with context about someone's movements, interests, and reflections.
In local mode, that information can stay on the machine.

Step 9: A public demo without pretending it's offline

I still wanted anyone to be able to try SIDEQUEST without installing Python, Ollama, or a local model.
So the public demo is deployed as:

React / Vite frontend
        ↓
      Render
        ↓
FastAPI backend
        ↓
Hosted AI inference

The hosted version is intentionally labeled as hosted.
The offline/on-device claim belongs to the local Ollama version, not the Render deployment.
That's an important distinction I wanted to keep honest.

🔎 A Technical Lesson: Fallbacks Shouldn't Hide Bugs

One of the useful lessons from building SIDEQUEST was that a fallback can make a broken system look healthy.
When generation fails, SIDEQUEST can safely fall back rather than showing a raw error to the user.
That's good product behavior.
But during development, a silent fallback could make it look like the AI was working when it wasn't.
So I kept the user experience graceful while making sure backend failures remain visible during development and debugging.
The principle is simple:
Fail safely for the user.
Fail loudly for the developer.

🔎 Another Lesson: Generated Text Is Still Input

SIDEQUEST feeds information from previous quests and user reflections back into later personalization and generation.
That means stored text should not automatically be treated as trusted instructions.
The generation pipeline separates structured application context from generated/user text and applies safety and validation before content becomes part of a new quest.
This matters because an AI system is not just vulnerable at the first prompt.
Its own previous outputs become future inputs.

🧠 Why Open Innovation Matters

A closed API would have made SIDEQUEST a different product.
The open-weight/local approach gives me something important:

The data can stay local In local mode, journey context, feedback and reflections can remain on the user's machine. That matters for a product dealing with personal routines and experiences.
The AI can work without internet access With Gemma running through Ollama, the local version can continue generating quests even when the network is unavailable. That means the model can go where the user goes. A park. A train. A neighborhood walk. Somewhere with no signal.
I can change the AI stack The AI isn't permanently tied to a single proprietary endpoint. The model can be replaced. The prompts can be inspected. The generation pipeline can be modified. The ranking layer can be changed independently of the model.
The important behavior stays in code I can inspect The safety filter, validation, candidate ranking and personalization logic aren't hidden behind a black box. That makes experimentation much easier. And for SIDEQUEST, that matters because the interesting part isn't just the model. It's the system around the model.

⚠️ Honest Limitations

SIDEQUEST is still a prototype, and there are things I would improve with more time.
The local model can still be generic
A smaller local model can occasionally produce predictable or less creative quests.
Semantic repetition isn't perfect
Similarity checks reduce obvious repetition, but they cannot guarantee that two experiences will feel completely different.
Safety filtering is not a guarantee
The current safety layer uses explicit filtering and validation rules. It reduces risky outputs but cannot mathematically guarantee that every real-world activity is safe.
Anonymous personalization isn't authentication
The current public version uses anonymous browser-level identity rather than account-based login.
Different browsers can maintain separate histories, but logging into a different Google/Chrome account within the same browser does not create a different SIDEQUEST account.
The hosted demo is not offline
The public Render deployment requires network access.
The offline claim applies to the local Ollama setup.
This is not a user study
The project has been tested through development and personal usage, but I have not run a formal user study or controlled experiment.
I would rather state that clearly than manufacture a number that sounds impressive.
🛠️ Tech Stack
Layer Technology
Frontend React + Vite
Backend FastAPI
Database SQLite + SQLAlchemy
Local AI Ollama
Open-weight model Gemma 3 4B
Validation Pydantic
AI pipeline Candidate generation + filtering + ranking
Deployment Render
Version Control Git + GitHub

🌍 The Bigger Idea

SIDEQUEST started from a very simple observation:
We don't necessarily need another app to tell us where to go.
We need better reasons to pay attention to where we already are.
The AI doesn't need to replace the world.
It just needs to make us notice it.
A good SIDEQUEST might take thirty seconds to read.
Then the screen disappears.
You walk.
You notice something.
You come back.
And the app has done its job.
My Agent Session

[Add your DevRelay agent session here]

🏆 Prize Categories

Best Use of Gemma
SIDEQUEST uses Google's open-weight Gemma 3 4B as the core generative model for creating personalized real-world sidequests.
The local implementation runs Gemma through Ollama, allowing the AI generation layer to run directly on the user's machine.
Best Use of Render
SIDEQUEST uses Render to deploy the public frontend and FastAPI backend so the project can be accessed as a live web application.
🔗 Links
Live Demo:
https://sidequest-jstk.onrender.com/
GitHub:
https://github.com/Bhavya4523/SIDEQUEST

Final Thought

Most AI products are trying to make you stay longer.
SIDEQUEST is trying to make you leave sooner.
The destination isn't the point.
The way there is.
#TouchGrass🌱

Remembering Why I Invested — I Built Investment Memory for My Dad

BHAVYA GOTHI — Sat, 03 Oct 2026 07:00:41 +0000

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

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

The Problem

My dad invests regularly, but there is a simple problem that becomes more noticeable over time:

You can remember that you bought something without remembering exactly why you bought it.

The original reason might have been a piece of news, a personal observation, a long-term plan, or a price at which he wanted to review his thinking.

Months later, that context can be difficult to reconstruct.

So instead of building another app that tells someone what to buy or sell, I built something much simpler:

Investment Memory — a personal journal for remembering the reasoning behind an investment decision.

What I Built

Investment Memory is a personal investment decision journal that I built for my dad.

He can record an investment using either text or voice.

For a voice note, the application first transcribes the recording. The resulting text is shown to the user so it can be edited before anything is saved.

The AI then extracts structured information from the note:

Stock name
Quantity
Purchase price
Why he invested
His stated intent
Time horizon
Review price
Review date

The extracted information is always editable before saving.

After an investment is recorded, the application provides:

Search across saved investment memories
Review reminders based on dates entered by the user
A "Mark reviewed" workflow
Review history
Editing of saved records
Light and dark mode

The most important design choice is that the application records the user's own decision and reasoning rather than generating investment recommendations.

Nothing is saved from the AI output until the user reviews and confirms it.

Demo

Live Demo: https://investment-memory-frontend.onrender.com

The public demo uses fictional/demo investment records rather than private family financial information.

The complete workflow is available:

Text
  ↓
Gemma extraction
  ↓
Human review and correction
  ↓
Save

AND

Voice
  ↓
Whisper transcription
  ↓
Editable transcript
  ↓
Gemma extraction
  ↓
Human review and correction
  ↓
Save

The deployed application also includes search, review reminders, review history, saved-record editing, and light/dark mode.

Code

GitHub: https://github.com/Bhavya4523/Investment-Memory

The repository contains the React frontend, FastAPI backend, SQLAlchemy models, AI integration, and deployment configuration.

How I Built It

I built Investment Memory with a React/Vite frontend, a FastAPI backend, SQLAlchemy, and a relational database.

The AI is at the center of the workflow.

Local-first version

For local use, the architecture is:

Voice / Text
     ↓
Whisper
     ↓
Gemma 3 4B
     ↓
Human review
     ↓
FastAPI
     ↓
SQLite

For voice input, the browser records audio and the backend uses faster-whisper to create the transcript.

For text extraction, I use Gemma 3 4B through Ollama.

The extraction prompt is deliberately constrained. The model is instructed to:

extract only information explicitly stated by the user
leave missing fields blank
avoid inventing information
avoid giving financial advice
treat a review price as a review point rather than a buy or sell instruction

The model output is then validated with Pydantic before it reaches the user interface.

Public deployment

For the public demo, I separated the infrastructure from the local setup:

React frontend
      ↓
FastAPI backend
      ↓
Hugging Face inference
   ┌───────────────┐
   │ Gemma         │
   │ Whisper       │
   └───────────────┘
      ↓
Neon PostgreSQL

The frontend and backend are deployed on Render, while Neon PostgreSQL stores the public demo records.

The same codebase supports both local and hosted AI through environment variables.

This gives the application two modes:

Local mode
→ Ollama
→ local Whisper
→ SQLite

and:

Hosted mode
→ Hugging Face
→ hosted Whisper
→ Neon PostgreSQL
Human-in-the-loop design

I did not want the model to silently turn a natural-language note into a permanent record.

The workflow is:

Capture
   ↓
AI extraction
   ↓
Human checks the fields
   ↓
Human corrects anything necessary
   ↓
Confirm & save

The user remains the source of truth.

Review memory

I also wanted an investment record to remain useful after the day it was created.

A user can set a review date.

When that date arrives, the application displays a due or overdue reminder.

After reviewing the investment, the user can:

record what they noticed
set another review date
save the review
view previous reviews later

Previous reviews are preserved in history instead of being overwritten.

Editing saved records

The user can also edit an existing investment record later.

This is useful when something was entered incorrectly because correcting the original record should not require creating another duplicate investment.

A deployment problem I encountered

The first Render deployment exceeded the available memory limit.

The reason was that the backend was importing the local faster-whisper dependency even though the hosted deployment did not need local Whisper.

I fixed this by loading faster-whisper only when the application is running in local mode.

That allowed the hosted backend to start without loading the unnecessary local speech-recognition stack.

This was a useful lesson for me: deployment is not just about getting the code to run. The application should only load the components that its current environment actually needs.

Why Does Open Innovation Matter?

For this project, open innovation mattered because I wanted the AI layer to be something I could control and adapt.

The local version uses Gemma 3 4B and Whisper with local inference.

Gemma 3 4B
+
Whisper
↓
Local processing

That makes the local version possible without building the entire application around a proprietary closed AI API.

It also gave me flexibility during development.

I could decide:

what information should be extracted
which fields mattered to the user
how missing information should be handled
how the output should be validated
what the application should do with the model's output

The AI model is not the final authority. It is one component in a larger system.

Another important benefit was portability.

I originally built the application around local inference, but a hackathon project also needs a way to demonstrate the result publicly.

Because the AI layer uses open models and a replaceable inference setup, I could move the public demo to hosted inference without redesigning the entire application.

That resulted in two useful configurations:

Local: a local-first personal version.

Hosted: a shareable demonstration version.

Open innovation therefore affected the architecture itself.

It allowed me to experiment with the AI locally, keep the model layer replaceable, and then move the application to a public deployment when I needed a shareable demo.

Built for My Dad

The most important part of this project is that it was built around a real person rather than a hypothetical user.

My dad was the reason I chose this problem.

I did not start by asking:

"What AI application can I build?"

I started with:

"What small problem does someone I know actually have?"

That led to a much narrower product.

Investment Memory is not trying to become a trading platform, a portfolio-management system, or an investment advisor.

It is a memory tool.

The goal is simple:

remember what you decided, remember why you decided it, and remember when you wanted to revisit that thinking.

What I Learned

The biggest lesson was that a useful AI application does not need to give the user more decisions.

Sometimes it is more useful to help the user remember their own decisions.

I also learned that making AI useful is as much about application design as it is about the model.

The model can extract information, but the surrounding system determines whether that extraction is trustworthy and useful.

That is why I added:

Editable extraction
+
Human confirmation
+
Persistent memory
+
Review history

rather than simply showing an AI-generated answer.

Prize Categories

I am entering the following partner categories because the project genuinely uses these technologies:

Best Use of Gemma
Best Use of Render

Gemma is used as the core language model for structuring investment notes, while Render hosts the deployed frontend and backend.
**
Final Thoughts**

I started with one small problem:

My dad remembers the investment, but over time the reasoning behind it can be forgotten.

The result became a small system for preserving that context.

There is no "What should I buy?" button.

There is no prediction engine.

There is no AI pretending to know what someone should do with their money.

Instead, there is a voice note, a memory, a structured record, and a future reminder to look back at the decision.

That was the application I wanted to build for one person I actually know.

DEV Community: BHAVYA GOTHI

Circular Sloth: The School WhatsApp Notices Your Brain Never Has to Read Twice Short, clear, and says exactly who it’s for.

What I Built

Demo

Code

Bhavya4523 / circular-sloth

Circular Sloth

Privacy and ownership

How I Built It

Why Does Open Innovation Matter?

Honest trade-off

Where open beat closed

The Lazy Payoff

Prize Categories

Pakka Khata — A Smarter Digital Khata for Small Indian Shops

What I Built

What it can do

Demo

Code

Bhavya4523 / pakka-khata-

Pakka Khata — Local-first digital khata for small Indian shops

Current status

How I Built It

TECHSTACK

Architecture and Implementation

Testing

Why Does Open Innovation Matter?

My Agent Session

My First User

Prize Categories

Pakka Khata — helping small shops keep their trusted khata, with a smarter way to manage it.

SIDEQUEST: Your Destination Isn't the Point

🌱 What I Built

What makes it different?

🎥 Demo

Try SIDEQUEST

💻 Code

Bhavya4523 / SIDEQUEST

⚙️ How I Built It

Step 1: Start with the real problem, not the AI

Step 2: Make the AI generate experiences, not recommendations

Step 3: Generate candidates, then choose

Step 4: Don't let the model decide what's safe

Step 5: Make repetition harder

Step 6: Let the system learn from the person

Step 7: Chaos Mode

Step 8: Local-first AI

Step 9: A public demo without pretending it's offline

🔎 A Technical Lesson: Fallbacks Shouldn't Hide Bugs

🔎 Another Lesson: Generated Text Is Still Input

🧠 Why Open Innovation Matters

⚠️ Honest Limitations

🌍 The Bigger Idea

🏆 Prize Categories

Final Thought

Remembering Why I Invested — I Built Investment Memory for My Dad

The Problem

What I Built

Demo

hf26challenge