Spark Dashboard
Consolidating 4 BI tools into one React app
Ownership
UI Developer
Team
Data Intelligence Team
Key Result
8s -> 2s Load Time
Overview
Internal analytics dashboard serving 50+ data analysts at Spark New Zealand. The brief: replace a patchwork of Power BI reports, Excel exports, and custom SQL queries with a single unified interface.
The Challenge
Four different tools meant four different data models, four authentication flows, and four sets of muscle memory. Analysts were spending more time switching contexts than analyzing data. The existing Power BI dashboards were slow (8-12 second loads), couldn't handle the query complexity analysts needed, and required IT tickets for any schema changes.
Constraints
- •Migration had to happen without breaking existing analyst workflows.
- •Database safety mattered as much as UI flexibility.
- •Legacy report logic had undocumented business assumptions.
Decision Log
Problem
Query state sharing broke with high filter counts.
Decision
Used URL params for critical state plus localStorage hash references for full state.
Tradeoff
More implementation complexity and some cache edge cases.
Impact
Shareable links for complex views without URL explosion.
Problem
Client-side rendering collapsed under large datasets.
Decision
Moved heavy aggregation to backend and shipped rollups.
Tradeoff
Reduced ad hoc pivot flexibility.
Impact
Interactive chart latency dropped to usable levels.
Approach
1. The State Problem
Analysts needed to build complex queries with multiple filters, date ranges, and aggregations - then share those exact views with colleagues. The naive approach (URL params) broke at ~15 filters. I ended up with a hybrid: critical filters in URL for shareability, full state persisted to localStorage with a hash reference. When you share a link, it includes a state hash. If the recipient has that state cached, instant load. If not, it rebuilds from URL params with sensible defaults. Not elegant, but it worked for queries with 40+ filter combinations.
2. The Performance Cliff
First version rendered all chart data client-side. Fine for 1,000 rows. Unusable at 50,000. Tried virtualization - helped with DOM, didn't help with the 3 seconds of JavaScript parsing. Solution: moved aggregation to the backend, only shipped pre-computed rollups to the client. Charts went from 3s to 200ms. Tradeoff: lost some query flexibility. Analysts could no longer do arbitrary client-side pivots. We added the 10 most common pivot patterns as backend options and accepted the limitation.
3. The Migration
Couldn't do a clean cutover - analysts had years of saved Power BI reports. Built an import tool that parsed .pbix files and extracted filter configurations, then mapped them to the new schema. Got about 70% accuracy. The remaining 30% required manual recreation, which surfaced edge cases in the old system that nobody remembered building. Documented everything. Some of those 'bugs' turned out to be intentional workarounds for data quality issues upstream.
Outcome
Dashboard shipped to 50+ users. Load times dropped from 8-12 seconds to under 2 seconds for most queries. Eliminated the IT ticket bottleneck for report changes - analysts could now modify views directly. Not everything worked. The query builder was too flexible initially; we had to add guardrails after analysts crashed the database with unindexed joins. Added query cost estimation and soft limits.
8s -> 2s
Load Time
50+
Users
4
Tools Replaced
Learnings
- →Performance optimization is often about moving work, not eliminating it. We didn't make the queries faster - we moved the heavy lifting to where it belonged (backend aggregation).
- →Migration is harder than building. Parsing legacy formats and mapping to new schemas took more time than the new UI.
- →Flexibility has costs. The 'let analysts do anything' approach almost killed the database. Constraints aren't just UX decisions - they're infrastructure protection.
- →Some bugs are features. Those weird Power BI workarounds existed for reasons. Document before you 'fix' them.
Anti-Patterns Avoided
- ×Unlimited free-form query execution against production tables.
- ×Big-bang migration without compatibility bridges.
- ×Treating analyst pain as a training problem instead of product debt.
Next Iterations
- →Query cost previews before run to prevent accidental heavy joins.
- →Saved-view governance with team-level ownership and audit trails.
Need This Type Of Outcome?
I run focused design engineering sprints for product teams.
If your team needs clearer UX, faster implementation, and measurable performance improvements, I can help.
Next project
Vape Quit Coach