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

> Source: <https://dev.to/bhavya_gothi_d9713c43c20b/remembering-why-i-invested-i-built-investment-memory-for-my-dad-2i89>
> Published: 2026-10-03 07:00:41+00:00

*This is a submission for the [Hacktoberfest Weekend Challenge: Build for a Friend](https://dev.to/challenges/hacktoberfest-weekend-2026-10-01)*

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

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.**

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:

The extracted information is always editable before saving.

After an investment is recorded, the application provides:

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.

**Live Demo:** [https://investment-memory-frontend.onrender.com](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](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.
