Splitzy
Offline-First Financial Expense Splitting System
“How do you build reliable financial software that remains correct even when users are offline?”
Case Study Index (5 Sections)↓
Problem & Product Goals
Expense splitting applications frequently suffer from floating-point arithmetic errors, overwrite-heavy database schemas that destroy edit histories, and balance discrepancies when users edit transactions. Splitzy addresses these issues with a CQRS-lite architecture separating the immutable command log from materialized read balances.
Standard expense splitters often introduce rounding errors when dividing odd amounts among friends, and editing past transactions can silently corrupt group balances. I wanted to design a ledger that treats financial accuracy as an uncompromisable engineering requirement.
Technical Architecture & Core Engine
The core financial engine uses BigInt integer paise values and remainder distribution algorithms to allocate exact paise remainders deterministically among split participants.
Design Philosophy: Immutability over mutations: never overwrite financial rows directly. Record every transaction edit or balance update as a signed, append-only event entry.
Engineering Decisions
IEEE-754 floating-point numbers in JavaScript introduce accumulation errors (e.g. 0.1 + 0.2 !== 0.3) that break financial totals.
Represented all currency strictly as positive BigInt integer paise with custom branded types.
Requires explicit conversion at input boundaries and UI display formatting.
Completely eliminated precision loss across all split calculations.
Updating balance records directly on expense edits makes historical auditing impossible and creates race conditions.
Implemented an append-only event stream where edits write compensating events processed atomically by PL/pgSQL database triggers.
Higher database storage footprint for transactional event history.
Created a 100% verifiable financial audit log for all group ledger changes.
Challenges & Solutions
Zero-Balance Exit Invariants
Issue: Preventing group members from leaving while holding un-settled debts using client-side checks was prone to bypasses.
Decision/Solution: Enforced the exit rule directly inside PostgreSQL database triggers (`prevent_member_leave_with_balance`), making bypasses impossible.
Development Timeline
Financial Core Spec
Defined integer-paise mathematical rules and event schemas.
PL/pgSQL Trigger Pipeline
Wrote database-level invariant enforcement triggers.
Offline Sync Engine
Built Zustand persistent offline mutation queue.
What's Next
Key Takeaways
Financial applications must represent money as integer atomic units rather than floating-point floats.
Append-only event streams preserve complete audit trails and prevent state corruption.
Pushing critical invariant rules into database triggers provides guarantees that client-side logic cannot replicate.
Related Engineering Projects
Vertex CampusOS
Built a multi-tenant university platform centralizing student registration state, class attendance rosters, club governance, and digital OD approvals.
SRM Academic Suite
Built a deterministic CGPA/SGPA grade calculator and target optimization tool used by student peers, featuring PDF report parsing.