I built Talliofi as a local-first personal finance app where your data lives on your device first and sync is optional. The goal was to make budgeting and planning useful right away, without forcing account setup or default cloud storage.
Product Outcome: It let people start budgeting immediately instead of asking them to hand over data before they had even tried the product.
Talliofi was built around a strict product stance: financial planning should work fully offline, with user data staying local by default. The challenge was delivering complex budgeting workflows with production UX while preserving privacy and correctness guarantees.
Most personal finance apps ask users to trust them with sensitive financial data. That is a real barrier for privacy-conscious users. The technical challenge was building a SaaS-quality experience (charts, budgets, tax estimation) entirely in the browser, with no backend, while keeping money calculations correct down to the penny.
Scope: Built a production-grade local-first finance system: domain engine, normalized data model, repository layer, sync strategy, and reporting UX.
Ownership: Owned architecture, implementation, QA strategy, and roadmap prioritization as founder-engineer.
This project was intentionally built in React to validate a framework-agnostic domain architecture. The same layering approach and quality gates directly informs my Angular system design on production teams.
I implemented strict boundaries: pure domain logic, validated persistence, repository routing, then UI consumption through query hooks. This made financial calculations testable without the framework and kept storage concerns swappable without rewriting feature code.
Rationale: localStorage has a 5MB limit and its synchronous API blocks the main thread. A finance app with budgets, transactions, and tax records needs structured data, indexed queries, and transactions. Dexie gave me a clean TypeScript abstraction over IndexedDB without hiding the power of the underlying API.
Outcome: 100% offline-capable finance management that handles complex financial modeling without performance degradation.
Rationale: Early in development, I found rounding discrepancies where budget totals were off by a few cents. The root cause was floating-point arithmetic. I switched all money values to integer cents and introduced branded TypeScript types so the compiler prevents you from accidentally adding dollars to cents.
Outcome: An entire class of rounding bugs disappeared. I wrote about this in detail: https://dev.to/emmanueln07/how-a-branded-cents-type-eliminated-an-entire-class-of-bugs-across-97-files-2o6o
Rationale: A finance dashboard with charting, forms, and analytics can get heavy fast. Splitting by route means users only download code for the feature they are actually using.
Outcome: Reduced initial payload meaningfully and preserved responsive dashboard interactions as features expanded.
Rationale: I deferred cloud sync to protect the MVP scope, but the architecture still needed to support it. A shared repository interface lets local-only, Supabase direct, and encrypted Supabase implementations be swapped without touching feature code.
Outcome: Talliofi ships fully local-first today and can add sync tiers later with minimal integration risk. I wrote about this architecture: https://dev.to/emmanueln07/your-financial-data-should-live-on-your-device-here-is-the-architecture-that-makes-that-possible-1764
Rationale: Storing pre-computed totals seems efficient, but in a finance app every write path has to update them perfectly or the numbers drift. Deriving summaries from source records on demand eliminates an entire category of consistency bugs.
Outcome: Dashboard metrics are always perfectly consistent with raw data. The calculation engine is pure, stateless, and easy to validate.
Before: N/A (new build)
After: 100% offline
Impact: Every feature works from the first load with zero connectivity
After: Consistently strong
Impact: Route-based code splitting and lazy loading
Before: Baseline (no splitting)
After: Measurable reduction
Impact: Route-based code splitting
After: 760+ tests
Impact: Domain unit tests caught 3 rounding edge cases, integration tests validated IndexedDB consistency, E2E confirmed critical user flows
Before: Floating-point arithmetic
After: Branded integer cents
Impact: Rounding errors eliminated at compile time
Decision: IndexedDB as source of truth
Risk: Cloud-first dependency increases onboarding trust friction and reduces offline reliability.
Change: Adopted local-first persistence with Dexie/IndexedDB and optional sync modes.
Result: 100% offline-capable default mode with strong automated quality coverage.
Source: Source
Decision: Repository strategy for storage tiers
Risk: Storage-mode changes can require expensive feature rewrites and increase roadmap risk.
Change: Implemented repo abstraction for local, direct-cloud, and encrypted-cloud variants.
Result: Storage complexity isolated to data layer; feature modules remain largely mode-agnostic.
Source: Source
Decision: Single source data model (Dexie + Query)
Risk: Multiple persisted state stores can drift and create stale or inconsistent UI states.
Change: Standardized on Dexie persistence with TanStack Query caching/mutation lifecycle.
Result: Reduced data-consistency risk and improved mutation reliability under growth.
Source: Source
| Decision | Risk | Change | Result | Source |
|---|---|---|---|---|
| IndexedDB as source of truth | Cloud-first dependency increases onboarding trust friction and reduces offline reliability. | Adopted local-first persistence with Dexie/IndexedDB and optional sync modes. | 100% offline-capable default mode with strong automated quality coverage. | Source |
| Repository strategy for storage tiers | Storage-mode changes can require expensive feature rewrites and increase roadmap risk. | Implemented repo abstraction for local, direct-cloud, and encrypted-cloud variants. | Storage complexity isolated to data layer; feature modules remain largely mode-agnostic. | Source |
| Single source data model (Dexie + Query) | Multiple persisted state stores can drift and create stale or inconsistent UI states. | Standardized on Dexie persistence with TanStack Query caching/mutation lifecycle. | Reduced data-consistency risk and improved mutation reliability under growth. | Source |
Incident: An early build exposed rounding discrepancies in monthly budget totals due to inconsistent arithmetic paths.
Response: Halted feature rollout, audited all money operations, and migrated calculations to strict integer-cents semantics.
Rollback: Kept summary widgets on source-of-truth recalculation paths while disabling unsafe cached aggregate writes.
Prevention: Added domain invariants and regression tests around money arithmetic, blocking merges that violate cents-only constraints.
Stack
Explore Other Work