Problem

Quicken's charting layer was built on amcharts4, a library with a large bundle footprint, limited documentation, and a difficult upgrade path. With 35+ distinct chart implementations across the product, the technical debt was compounding. The team needed a path to a more maintainable, performant, and actively-supported solution without disrupting live features.

Approach

Conducted thorough research and comparative analysis across multiple charting libraries before settling on eCharts as the target. Performance benchmarking was a key part of the decision: eCharts was up to 70x faster than amcharts4 in rendering tests on data-heavy charts. Established a reusable visualization architecture and a shared set of interaction standards so every migrated chart behaves consistently, then produced detailed documentation covering migration patterns, API differences, and a component-by-component porting strategy. Charts are being migrated incrementally, with cross-team stakeholder coordination to prioritize order and manage risk across a large surface area.

Outcome

Migration is actively in progress. The 70x rendering improvement on heavy charts is immediately noticeable to users. The incremental rollout has kept live features stable throughout, and the documentation-first approach has made it straightforward for other engineers to pick up and contribute to the migration.

Problem

After the Reports rebuild gave users a powerful interactive reporting experience, there was no way to preserve that work. Every time a user opened Reports they started from scratch with no saved views and no way to return to a configuration they had spent time setting up. For business users who run the same reports regularly, this was a real friction point.

Approach

Designed the API contract for report persistence in collaboration with backend, then built the full client-side document management layer: Save, Save As, Rename, and tab-based management for multiple open reports. The tab system required careful state management so each tab maintained its own independent report configuration, and switching between tabs felt instant without re-fetching.

Outcome

Users can now build a report once and return to it. The tab model maps naturally to how people actually use reports, running several views in parallel, and the Save As flow makes it easy to create variants without overwriting existing work. The underlying API and state architecture proved extensible enough that I recently reused it to author the API specification and data contracts for Comparison Reports, a new feature for comparing report data across time periods.

Problem

Two compounding problems drove the rebuild. The existing implementation had two sources of truth, a React context and a Redux store, that were meant to stay in sync but would drift and cause the app to loop trying to reconcile them. On top of that, business users had a real unmet need: the original reports were just a chart with a flat transaction list underneath. For accounting and deep financial analysis they needed something much closer to Excel pivot table behavior, with interactive rows, columns, and groupings while the chart updated alongside.

Approach

Consolidated all report state into Redux and removed the React context layer entirely. Then built an interactive data grid on top of that stable foundation, supporting drill-down into categories, dynamic row and column configuration, filtering, and autosave, while keeping the chart in sync with whatever view the grid was showing. The chart and grid share the same derived state so they always agree.

Outcome

Delivered a reports experience that genuinely works for power users doing accounting and financial analysis. Resolved the state synchronization bugs that had been a persistent source of issues and established a cleaner architecture for the feature going forward.

Problem

Spending Plan, Simplifi's primary monthly budgeting view, had a persistent 2-second lag on common interactions. The page is highly interactive and users are constantly adjusting values and seeing the effect on their budget, but every interaction was round-tripping to the server for recalculation, making it feel sluggish.

Approach

Transactions were already loaded client-side as part of our existing architecture, and we had already built optimistic update patterns on the transactions page we could leverage directly. The fix was moving budget calculations entirely to the client, computing derived state from the transaction data already in Redux rather than waiting on a server response. Added a comprehensive Jest test suite and coordinated a cross-team test plan to validate the client-side calculations.

Outcome

Interaction latency dropped from 2 seconds to under 50ms, a 40x improvement. Because the approach reused existing optimistic update infrastructure rather than building something new, it was lower risk than it sounds and shipped cleanly. The test suite became the standard for the feature going forward.