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

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

The Problem

What I Built

Demo

hf26challenge