RecallIQ — Part 4 of 5
A practical look at how RecallIQ was developed, tested, and refined during the hackathon, including the engineering decisions, security practices, and lessons learned along the way.
Building for a Hackathon
A hackathon rewards a working demo.
But a working demo is not the same as an honest one.
When building RecallIQ, one of the main goals was to move quickly without making claims about features that had not actually been verified.
The project was developed around a simple principle:
Build the smallest useful system, test each layer independently, and clearly separate what works from what is still being developed.
This approach helped keep the project understandable while leaving room for future improvements.
Choosing a Stack for Speed and Clarity
RecallIQ uses a relatively lightweight technology stack:
| Layer | Technology |
|---|---|
| Frontend | React, TypeScript and Vite |
| Backend | Python and FastAPI |
| Data Validation | Pydantic |
| Memory | Hindsight Cloud |
| Development | Cursor / Code Editor |
| API Testing | FastAPI Swagger UI |
| Environment | PowerShell and Browser |
Each component was selected for a practical reason.
React + TypeScript + Vite
The frontend provides a responsive dashboard while TypeScript helps catch mistakes in how application data is handled.
Vite also provides a fast development feedback loop, making it easier to see frontend changes quickly.
Python + FastAPI
FastAPI provides a lightweight backend framework with automatic API documentation.
This was particularly useful during development because the API could be tested independently before the complete frontend workflow was connected.
Pydantic
Pydantic handles data validation.
Instead of allowing malformed decision objects to travel deeper into the application, invalid requests can be rejected early.
Hindsight Cloud
Hindsight provides the persistent-memory layer.
This allows RecallIQ to experiment with retaining and recalling decision context beyond a single application interaction.
Backend First, Dashboard Second
One of the most useful development decisions was to prove the backend before building the interface on top of it.
FastAPI's automatically generated Swagger UI made this possible.
Each endpoint could be tested directly from the browser.
The workflow was:
```text id="r1m5y2"
Define Data Model
↓
Build API Endpoint
↓
Test in Swagger UI
↓
Verify Response
↓
Connect Frontend
This reduced debugging complexity.
If something failed in the dashboard, we could first check whether the backend endpoint itself was working.
That made it easier to distinguish between:
* Frontend problems
* Backend problems
* Memory-service problems
---
## The Development Workflow
The development process followed a sequence of small, testable steps.
### Step 1 — Define the Decision Model
The first step was defining what information a decision should contain.
The model includes:
* Title
* Description
* Assumptions
* Expected outcome
* Status
The status can represent:
* Pending
* Successful
* Failed
* Warning
This structure gives each decision enough context to be useful later.
---
### Step 2 — Build Decision Creation
The next step was creating the decision endpoint.
```text id="b9t2gx"
POST /api/decisions
A valid request creates a decision and returns an appropriate success response.
The expected HTTP status for successful creation is:
201 Created
This endpoint became the foundation for the rest of the application.
Step 3 — Retrieve Decisions
The next endpoint was:
```text id="o7d5xj"
GET /api/decisions
This allows recorded decisions to be retrieved from the running backend.
Testing this immediately after creation helped verify that the application was correctly handling the decision data.
---
### Step 4 — Connect Hindsight
Once the basic decision flow worked, Hindsight Cloud was introduced as the memory layer.
When a decision is created, relevant information can be sent to Hindsight for retention.
The important information includes:
* Decision context
* Reasoning
* Assumptions
* Expected outcome
The purpose is to make the decision available for future recall.
---
### Step 5 — Build Memory Recall
The next step was testing memory retrieval.
```text id="ps5z7x"
POST /api/memories/recall
The backend sends a query describing a situation and receives relevant memories.
This was an important stage because persistent memory is only useful if the system can retrieve relevant information when it is needed.
Testing different query descriptions helped build an understanding of how the memory service responds to different situations.
Step 6 — Connect the Dashboard
Only after the backend workflow was tested independently was the React dashboard connected to the API.
This created a clear separation:
```text id="g3kz5r"
Frontend
↓
FastAPI API
↓
Application Logic
↓
Hindsight Cloud
This approach also made debugging easier.
---
## What Has Been Tested
Being precise about testing status matters more than sounding impressive.
At the current stage:
### Tested Successfully
* Decision creation
* Decision retrieval
* Hindsight memory interaction
* Memory recall
* Backend API workflow
* Frontend/backend communication
### Still Being Verified
The analysis functionality and its complete integration with the dashboard require further verification.
Therefore, we avoid claiming that every planned analysis feature is already available as a fully verified user-interface workflow.
This distinction is important.
There is a difference between:
> "The code exists."
and:
> "The complete feature has been tested and is ready for users."
RecallIQ aims to describe the second category only when it has actually been verified.
---
## Working With an External Memory Service
Adding an external memory service introduces a different type of engineering challenge.
Creating a decision is no longer just a local operation.
The application may need to:
```text id="f1nyw8"
Receive Decision
↓
Validate Request
↓
Record Decision
↓
Contact Hindsight
↓
Retain Memory
The Hindsight request can fail because of:
- Network problems
- Service availability
- Invalid credentials
- Incorrect request data
- Other external-service errors
This means the application should not blindly assume that an external call always succeeds.
The word "attempts" is important when describing memory retention.
The backend attempts to retain the decision, but an external service should always be treated as a possible point of failure.
Testing Memory Recall
Testing a memory system is different from testing a normal database query.
A database query might return an exact matching record.
Memory recall instead focuses on relevance.
For example, a query about:
"Reducing cloud infrastructure costs"
may recall a previous decision involving:
"Migrating workloads to a cheaper cloud provider."
The wording does not have to be identical.
This makes semantic relevance important.
During development, different query descriptions were useful for understanding how the memory layer responded.
This also highlighted an important principle:
The quality of memory recall depends on both the information that was retained and how the new situation is described.
Handling Secrets Properly
One of the simplest but most important practices was protecting API credentials.
The Hindsight API key is stored in a backend environment file and loaded through environment variables.
The basic rules are:
Never Commit .env
Environment files containing secrets should be excluded from version control.
Never Put API Keys in Source Code
Credentials should not be hardcoded into application files.
Never Share Credentials in Documentation
API keys should not appear in:
- Screenshots
- README files
- Articles
- Presentations
- Public repositories
Keep Secrets Behind the Backend
The frontend should not need direct access to the Hindsight API key.
Instead:
```text id="kq3o9w"
React Frontend
↓
FastAPI Backend
↓
Hindsight Cloud
This keeps the credential on the server side rather than exposing it to the browser.
---
## Being Honest About the Prototype
The biggest lesson from building RecallIQ was that limitations should be stated early.
Three limitations are particularly important.
### 1. Storage Is Not Yet a Production Database
The current decision records are held in application memory.
This means they may reset when the backend restarts.
A production implementation should use persistent storage such as PostgreSQL.
### 2. Analysis Is Limited
The current approach uses predefined logic rather than relying on an LLM to generate the analysis.
This makes the system transparent, but it also means that it can only identify patterns that have been explicitly defined.
### 3. Humans Stay Responsible
RecallIQ is a decision-support system.
The output should not be treated as an autonomous decision.
A person should review the information before taking action.
---
## Why These Limitations Matter
It may seem strange to emphasize limitations in a hackathon article.
But doing so actually improves the technical credibility of the project.
A prototype does not need to pretend to be production-ready.
Instead, every limitation can become a roadmap item.
For example:
```text id="l3k1w4"
In-Memory Storage
↓
PostgreSQL
Rule-Based Analysis
↓
Grounded LLM Analysis
Basic Decision Record
↓
Outcome Tracking
Single Prototype
↓
Team Workspaces
The current system therefore provides a foundation rather than pretending to be the final product.
Lessons for Other Builders
Several lessons from developing RecallIQ are useful beyond this project.
Test the Backend Independently
Swagger UI can act as an API test bench.
Testing the backend separately makes it easier to identify where problems occur.
Separate Memory From Reasoning
Memory retrieval and decision analysis are different responsibilities.
Keeping them separate makes the architecture easier to understand and modify.
Track Claims Against Evidence
For every feature described in documentation, ask:
Has this actually been tested?
If the answer is no, describe it as planned or under development rather than completed.
Protect Secrets From Day One
It is much easier to prevent a credential from being exposed than to clean up a leaked credential later.
Prefer Honest Scope
A smaller system with accurate claims is more useful than a large description filled with features that have not been verified.
What We Would Improve Next
The current development experience points toward several improvements.
Persistent Database
Move decision records from application memory to PostgreSQL or another production database.
Better Analysis
Introduce more sophisticated contextual analysis while keeping the reasoning traceable.
Outcome Tracking
Record what actually happened after a decision and compare it with the expected outcome.
Better Memory Relevance
Improve filtering and retrieval so that users see the most useful historical decisions.
Citations
Connect recommendations to the exact historical decisions that support them.
Authentication
Introduce user accounts and team-level access control.
Evaluation
Measure whether the recommendations are actually useful rather than assuming they are.
The Development Philosophy
The technical choices behind RecallIQ can be summarized in a few principles:
Build incrementally.
Test each layer independently.
Keep responsibilities separated.
Protect credentials.
Track claims against evidence.
Be honest about limitations.
These principles are not specific to RecallIQ.
They are useful when building almost any AI-enabled application.
Conclusion
RecallIQ came together quickly because the technology stack encouraged short development and testing cycles.
FastAPI made it possible to test the backend independently.
React and TypeScript provided the dashboard layer.
Pydantic provided structured validation.
Hindsight Cloud provided the persistent-memory component.
Most importantly, the project stayed grounded by distinguishing between what had been implemented, what had been tested, and what remained on the roadmap.
A hackathon project does not need to be perfect.
It needs to demonstrate a meaningful idea, show a working foundation, and communicate clearly what exists today and what can come next.
RecallIQ's development process reinforced that principle:
Build fast, test honestly, and make the next improvement obvious.
Explore RecallIQ
🔗 GitHub Repository: https://github.com/ravikanthbojja44-create/Recall-IQ
RecallIQ is currently a prototype and does not have a public live demo deployed yet.
RecallIQ Series
⬅️ Part 1 — The Problem of Forgotten Decisions: Why AI Systems Need Persistent Memory
⬅️ Part 2 — Inside RecallIQ: Building a Decision-Memory System with FastAPI, React and Hindsight Cloud
⬅️ Part 3 — Memory Plus Rules: Designing Trustworthy Decision Analysis Without an LLM
Part 4 — Building RecallIQ: Development Workflow, Testing and What We Learned ← You are here
➡️ Part 5 — From Decision Memory to Decision Learning: The Future of RecallIQ
This article is Part 4 of the RecallIQ technical series exploring persistent memory, trustworthy decision support, and the evolution from decision memory to decision learning.
Top comments (0)