Financial data systems
MyBursar
A privacy-focused personal-finance application for organizing financial activity and turning it into understandable, actionable decisions.
- Node.js
- Supabase
A user-owned financial source with balances, freshness information, and imported activity.
Provenance · Reconciliation · User corrections · Data deletion
01 / Context
What it solves
Personal finances are often fragmented across institutions, statements, subscriptions, debts, budgets, and future goals. A balance alone does not explain where money is going or what action would improve the situation.
MyBursar was designed as a private workspace that could bring those pieces together while keeping the user in control of imported data, corrections, and the insights produced from it.
02 / Product shape
From financial activity to useful decisions
The useful product loop is not simply importing more data. It is turning imperfect records into a view the user can understand, verify, and act on.
- 01Bring in account activity or statements
- 02Normalize transactions into a consistent model
- 03Review categories and recurring costs
- 04Plan budgets, debts, subscriptions, and goals
- 05Surface relevant financial insights
- 06Let the user correct and control the record
03 / Requirements
What the system needs to handle
- Accept financial records from more than one source without losing where each record came from.
- Represent transactions consistently enough to support budgets, recurring expenses, debts, and goals.
- Keep calculations explainable and traceable to the underlying financial activity.
- Handle duplicate, incomplete, stale, or malformed source data without silently corrupting the user's view.
- Treat financial records as sensitive data throughout access, processing, and deletion workflows.
- Make automated categorization and insights correctable rather than presenting them as unquestionable conclusions.
04 / Architecture
Engineering decisions
Normalize before generating insights
Linked-account data and uploaded statements can describe the same financial activity in different shapes. A consistent transaction model provides a dependable base for calculations and prevents every feature from interpreting raw source data independently.
Preserve source provenance
A normalized record still needs a connection to its origin. Source identifiers, import context, and user corrections make duplicates easier to investigate and allow an insight to be traced back to the activity that produced it.
Derive summaries from financial records
Balances, budget progress, debt movement, and subscription totals should come from the underlying records wherever practical. This limits contradictory totals and gives the product one place to correct an error.
Separate calculations from interpretation
Deterministic financial calculations should remain distinct from higher-level insight generation. That boundary makes factual numbers easier to verify and prevents helpful suggestions from being confused with authoritative financial advice.
05 / Trust
Reliability and privacy
Financial software earns trust through correctness, clear uncertainty, and user control. A polished insight is not useful if its source data is stale, duplicated, or impossible to correct.
Duplicate-aware imports
Repeated synchronization and overlapping statements can produce the same transaction more than once. The design calls for stable source identifiers or careful fingerprints so an import can be retried without inflating balances and spending.
Visible partial failures
A statement may contain valid rows alongside records that cannot be parsed. Import results should distinguish accepted, rejected, and unresolved items so the user can recover without guessing what entered the system.
Freshness as part of the data
Balances and transaction feeds can become stale when a provider stops synchronizing. Recording when information was retrieved allows the interface to communicate uncertainty instead of presenting old data as current.
Minimize sensitive exposure
The privacy direction is to retain only the information needed for the product's workflows, isolate records by user, avoid exposing provider credentials, and make account deletion behavior explicit.
06 / Reasoning
Trade-offs
- Linked accounts reduce manual work, but introduce provider availability, synchronization delays, and a larger security boundary.
- Statement imports give users another path and more control, but inconsistent formats make validation and error reporting substantially harder.
- Automatic categorization makes the product faster to use, while user overrides are still necessary because financial context cannot always be inferred reliably.
- Node.js and Supabase keep the system approachable for a private product, but specialized reconciliation or processing boundaries may become useful if import volume and source variety increase.
07 / Status
Current status
MyBursar was developed during 2025 as a private personal-finance project. It explored how transactions, budgets, debts, subscriptions, goals, and document-based imports could fit within one user-controlled workspace.
The project remains private. The most useful architectural direction for a future iteration would be to formalize import provenance, reconciliation states, and data-freshness rules before expanding automated insights.
08 / Reflection
What the product direction makes clear
- Financial insights are only as trustworthy as the records and calculations beneath them.
- Imports need provenance and reconciliation, not just a successful upload message.
- Users must be able to understand and correct automation that affects their financial picture.
- Privacy, deletion, and data freshness belong in the product model from the beginning.