This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.
What I Built
Poolfolio is a group investment management app I built for my friends who pool money together to invest in stocks and IPOs. We were managing contributions, ownership, profit/loss, and eventual settlement manually. Different people could contribute different amounts, and every investment could involve a different set of members. That created a simple but important accounting problem: Who owns what? Poolfolio makes that calculation investment-specific and automatic. For every investment:
ownership percentage = member contribution / total contribution
Profit or loss is then allocated according to those ownership percentages.
For example, if:
A contributes ₹10,000
B contributes ₹20,000
C contributes ₹70,000
their ownership becomes:
A → 10%
B → 20%
C → 70%
If the investment makes a ₹20,000 profit:
A → ₹2,000 profit
B → ₹4,000 profit
C → ₹14,000 profit
The app also treats every stock/IPO investment as a separate investment instance, even when the same stock is purchased again later.
Another important part of Poolfolio is the investment lifecycle:
DRAFT → OPEN → LOCKED → ACTIVE → SETTLED
While an investment is OPEN, contribution amounts can be managed.
Once it becomes LOCKED, the contribution basis becomes immutable so that ownership and historical accounting cannot be silently changed later.
The goal isn't to replace Angel One, Groww, or another broker.
It is to solve the messy accounting and coordination problem around investing together as a group.
Demo
1. Dashboard
The dashboard provides an overview of the user's investment groups, investments, active investments, and portfolio information.
2. Create a Group
Users can create an investment group. The creator is automatically assigned as the group LEADER.
3. Group & Members
Each group has its own members and investment history. Roles are used to control who can manage the group's investments and financial records.
4. Create Investment
Poolfolio supports both stock and IPO investments.
Each investment is treated as an independent investment instance with its own contribution, transaction, ownership, P&L, and settlement history.
5. Investment Overview
The investment overview brings together:
Ownership
Locked capital
Current value
Contributions
Ledger
P&L
AI audit
PDF reporting
The application keeps the accounting logic on the backend so that the mobile UI is never the source of truth for financial calculations.
6. Profile
The profile section provides account information and the user's Poolfolio activity.
Deployed Backend
The backend API is deployed on Render.
Source Code
How I Built It
Poolfolio uses a backend-first architecture because financial calculations need a single source of truth.
Technology Stack
Mobile
React Native
Expo
TypeScript
Expo Router
NativeWind
TanStack Query
React Hook Form
Zod
Expo SecureStore
Backend
Node.js
Express
TypeScript
Prisma
PostgreSQL
JWT authentication
Argon2 password hashing
AI
Gemma
TabPFN
Infrastructure
Render
Sentry
Backend-First Accounting
One of the most important architectural decisions was keeping financial calculations out of the mobile application.
The mobile app displays the results, but the backend is responsible for calculating and validating:
Ownership
Profit/loss
Settlement
Transaction totals
Investment state
Contribution locking
For every investment:
member ownership = member contribution / total investment contribution
The investment-level profit or loss is:
profit/loss = final investment value - total invested capital
And each member's share is:
member profit/loss = investment profit/loss × ownership percentage
Finally:
member settlement = original contribution + member profit/loss
The accounting engine is deterministic.
AI is never allowed to decide financial calculations.
Contribution Locking
A major business rule in Poolfolio is the OPEN → LOCKED boundary.
While an investment is OPEN, members can manage their intended contribution.
Once an investment becomes LOCKED, the contribution basis becomes immutable.
This is important because changing a member's contribution after an investment has been executed could change their ownership percentage and therefore change historical profit/loss and settlement calculations.
Poolfolio therefore treats the locked contribution as the ownership basis for that particular investment.
Investment Lifecycle
Every investment follows a controlled lifecycle:
DRAFT ↓ OPEN ↓ LOCKED ↓ ACTIVE ↓ SETTLED
Cancellation is allowed only before the investment becomes locked:
DRAFT → CANCELLED OPEN → CANCELLED
Once an investment reaches LOCKED, its financial basis is protected.
This prevents arbitrary state changes from corrupting the accounting history.
Ledger-Based Financial History
Poolfolio does not treat a single editable balance as the complete history of an investment.
Instead, financial events are preserved as ledger transactions.
The system supports transaction types such as:
CONTRIBUTION WITHDRAWAL BUY SELL ALLOTMENT REFUND DIVIDEND FEE TAX ADJUSTMENT
This is particularly important for IPOs.
For example, if a member applies for ₹20,000 but only ₹8,000 is allotted:
Applied amount = ₹20,000 Allotted amount = ₹8,000 Refund = ₹12,000
The actual invested capital becomes ₹8,000 while the application and refund history remains preserved.
AI at the Core
==============
Open-source AI is not just an optional chatbot feature in Poolfolio.
It is integrated into the financial-data workflow.
Gemma — Financial Document Extraction
One of the core AI workflows is extracting structured transaction information from unstructured financial documents.
A broker statement, transaction document, IPO allotment document, or similar record can contain information that would otherwise need to be manually entered.
The workflow is:
Financial Document ↓ Preprocessing / OCR ↓ Gemma ↓ Structured JSON ↓ Schema Validation ↓ User Review ↓ User Confirmation ↓ Financial Ledger
The important design decision is that Gemma does not directly write financial information into the database.
Instead:
Gemma extracts information.
The backend validates the extracted structure.
The user reviews the result.
The user confirms it.
Only then is the financial record written to the ledger.
This provides the convenience of AI-assisted data entry without allowing a probabilistic model to silently alter financial records.
TabPFN — Transaction Anomaly Detection
Poolfolio also uses TabPFN to analyze historical transaction data and surface potentially unusual transaction patterns.
The intended relationship between the AI components is:
TabPFN ↓ Detect potentially unusual patterns ↓ Gemma ↓ Explain the result
The anomaly detection system is an investigation aid.
It is not intended to make a definitive fraud determination.
Why Does Open Innovation Matter?
Poolfolio deals with sensitive financial information such as:
Transaction statements
Investment amounts
Member contributions
IPO applications
Allotments
Refunds
Settlement information
That makes control over the AI layer particularly important.
Using an open-weight model such as Gemma gives Poolfolio the ability to build the AI workflow around open/local inference rather than making the entire application dependent on a closed proprietary AI API.
It also makes the AI layer more replaceable and adaptable.
The application can evaluate different models and inference strategies without redesigning the entire financial system around one proprietary provider.
But the most important reason is architectural control.
Poolfolio deliberately separates AI from accounting.
AI is used for:
Document interpretation
Structured information extraction
Explanation
Anomaly analysis
Deterministic backend code is responsible for:
Ownership
Profit/loss
Settlement
Transaction validation
Financial state transitions
This means the application gets the benefits of AI while keeping the actual financial calculations deterministic.
For a financial application, I believe this separation is more important than simply adding an AI chatbot.
Security and Data Integrity
Because Poolfolio handles group financial information, authorization is enforced on the backend.
The application has three roles:
LEADER
Can:
Manage the group
Manage members
Create investments
Manage investment lifecycle
Manage transactions
Generate reports
CO_LEADER
Can:
Manage investments
Manage transactions
Generate reports
MEMBER
Can:
View the group
View investments
View their contributions
View ownership
View P&L
View settlement information
Members cannot modify other members' financial information.
Poolfolio also enforces cross-group authorization.
A user who is a leader of Group B cannot access or modify investments belonging to Group A simply by knowing the investment ID.
All protected operations are validated against the authenticated user's identity and actual group membership.
Testing
The backend was developed with automated tests covering authentication, groups, roles, investments, authorization, lifecycle transitions, and cross-group security.
The investment module includes tests for:
Investment creation
Role authorization
Cross-group access
Duplicate-symbol investment instances
Investment retrieval
Filtering
Lifecycle transitions
Invalid lifecycle transitions
Cancellation
Locking
Deletion protection
The project also includes type checking and production build verification.
The goal was not just to make the UI work, but to enforce the important business rules at the backend level.
What I Learned
The most interesting part of building Poolfolio was realizing that the difficult problem wasn't displaying portfolio numbers.
It was defining exactly what those numbers meant.
For example, changing a member's contribution after an investment has been executed sounds like a simple CRUD operation.
It isn't.
Once an investment is locked, changing that amount changes the ownership basis and potentially changes historical P&L and settlement.
That led to one of the central rules in Poolfolio:
OPEN → contributions can change LOCKED → contribution basis is immutable
Designing around this boundary forced me to think about Poolfolio as an accounting system rather than simply another CRUD application.
I also learned that integrating AI into a financial application requires a different approach from simply putting an LLM behind an API endpoint.
The model can assist with interpretation and explanation, but it should not become the source of truth for financial calculations.
Why I Built It
This project started from a real problem in my friend group.
We wanted to invest together, but managing different contribution amounts, different investments, ownership percentages, profits, losses, and settlements manually becomes difficult very quickly.
We didn't need another generic stock portfolio application.
We needed an answer to a much more specific question:
"How much did everyone put into this investment, what percentage does each person own, how much did we make or lose, and what does everyone get back?"
Poolfolio is my attempt to solve exactly that problem.
The application is designed around the way a real group investment pool operates rather than around a generic portfolio-tracking workflow.
Prize Categories
Best Use of Gemma
Gemma is used as the open-weight AI model for extracting structured transaction information from financial documents.
The model is integrated into the actual financial-data ingestion workflow rather than being used only as a conversational feature.
Best Use of TabPFN
TabPFN is used to analyze historical transaction features and surface potentially anomalous transaction patterns for further review.
Best Use of Render
The Poolfolio backend is deployed on Render.
Links
GitHub:https://github.com/Heramb1221/poolfolio
Backend:https://poolfolio-api.onrender.com
Built for a Friend
Poolfolio was built for a real problem faced by my friends and me.
The project started with a simple question:
Who owns what?
It ended up becoming a much deeper engineering problem involving accounting rules, immutable financial history, lifecycle management, authorization, transaction ledgers, AI-assisted document processing, and anomaly detection.
That is what made this project interesting to build.
Instead of building something just to demonstrate a technology, I built something around a problem that actually existed.
Built during the Hacktoberfest Weekend Challenge: Build for a Friend.
Top comments (0)