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

A developer built Investment Memory, a personal investment decision journal for his father that records the reasoning behind each investment rather than generating buy or sell recommendations. The app accepts text or voice input, using faster-whisper for transcription and Gemma 3 4B via Ollama for structured extraction, with every AI output validated by Pydantic and requiring human review before saving. The same codebase runs in a local mode (Ollama, local Whisper, SQLite) and a hosted mode (Hugging Face inference, Neon PostgreSQL) deployed on Render.

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.