P2P Budgeting
Purpose
Build a personal financial tool that helps users understand which money is already spoken for so they can avoid accidental overspending and future cash-flow stress. Instead of enforcing rigid monthly budgets, the app focuses on forward-looking obligations and answers one concrete question:
“How much money do I need to not touch in the next 30 days?”
Problem Statement
Traditional budgeting tools assume stable income and predictable monthly patterns. In reality, income and expenses often change month to month due to travel, job transitions, or new fixed costs. Because future obligations are not clearly visible, it’s easy to assume more money is available than actually is. This creates a mismatch between perceived and real availability of cash, leading to short-term decisions that cause long-term stress. Existing tools either require heavy manual categorization or obscure cash-flow timing behind monthly summaries.
User Story
When I look at my bank balance, I want to understand which portion of that money is already committed to upcoming recurring expenses. I want to clearly see what cash must be reserved in the near future so I can make spending decisions without accidentally putting myself in a bad position.
Design Philosophy
- Cash flow over categories: Timing and obligations matter more than labels.
- Forward-looking, not judgmental: The app reports facts without guilt or scolding.
- Automation first: The system does the work; the user confirms only when necessary.
- Change is expected: Life transitions are normal, not budgeting failures.
- Clarity beats completeness: One honest insight is better than many noisy dashboards.
Core Concept (V1)
The app identifies recurring expenses from historical transactions and forecasts when they will occur in the next 30 days. It then calculates how much money must be reserved to safely cover those expenses. This reserved amount represents money that is not truly available to spend, even if it is currently sitting in the account.
Definition: Recurring Expense (V1 Heuristic)
A transaction is considered recurring if:
- It appears at least 2–3 times in the uploaded history
- The transaction amount is identical
- The time between occurrences is consistent (±3 days)
- Similar transaction descriptions are a bonus but not required
This rule is deterministic, explainable, and intentionally simple for V1.
V1 Scope (Strict)
Input
- User uploads a CSV of bank transactions (past 1–2 months)
- The most recent balance in the CSV is treated as the current balance
Processing
- Parse and store transactions
- Detect recurring expense patterns
- Forecast recurring expenses for the next 30 days
- Estimate dates and total required cash
Output
- A timeline visualization showing:
- Upcoming recurring expenses
- Expected dates money will leave the account
- One primary number:
- Total amount required to cover recurring expenses in the next 30 days
- A short explanation of assumptions and detection logic
Explicitly Out of Scope for V1
- Income modeling
- “Safe to spend” calculations
- Categories and budgets
- Bank API integrations (Plaid)
- Notifications or alerts
- Long-term forecasting
- Manual transaction-by-transaction classification
These features may be layered on later, but not before V1 is complete.
UX (V1)
- Minimal, single-focus interface
- One timeline view showing money leaving the account
- One summary number indicating reserved funds
- Clear language emphasizing “committed” vs “available” money
The goal is to make invisible obligations visible, not to overwhelm the user.
Technology Stack
Frontend
- React
- Familiar and fast to iterate
- Mobile-first UI
- Focused on clarity over visual density
Backend
- Go
- Explicit control over data processing
- Simple, predictable logic for pattern detection
- Aligned with professional development goals
- PostgreSQL
- Relational structure fits transaction and pattern data
- Production-grade and open source
- Supports future expansion without rework
Infrastructure
- Docker
- Isolates database and backend services
- Ensures consistent local development
- Reduces environment-related friction
Implementation Plan
- CSV ingestion and parsing
- Persist transactions in the database
- Implement recurring expense detection
- Forecast recurring expenses for the next 30 days
- Display timeline and reserved amount
Feature additions are explicitly deferred until this flow is complete and usable.
Review & Iteration
After V1:
- Evaluate accuracy and trustworthiness of recurring detection
- Identify where users feel confused or unsupported
- Decide whether to introduce income modeling or “safe to spend” calculations next
- Expand scope only if it directly improves decision-making clarity