A dashboard that survived scale

The first version of the dashboard was built for a demo and a dozen friendly stores. It rendered every order the merchant had ever made and did the maths in the browser. It was fast, because the datasets were small.

Then it wasn't.

What actually broke

Not the framework. Not the charts. The problems were all at the seams:

• The API returned everything. A store with 40,000 orders shipped 40,000 rows to the client on every page load.
• Date math ran on the main thread. Grouping a year of orders by week locked the tab for a second on a mid-range phone.
• State was a soup. Filters, the date range, and the fetched data were three separate sources of truth that disagreed during loading.

What fixed it

Move the aggregation to the server and return only what a chart needs — buckets, not rows. Make the date range the single source of truth, and derive everything else from it. Treat "loading" as a real state, not the absence of data.

None of this is clever. It's the unglamorous work of deciding what the client is for: rendering a shape someone already computed, not computing it. The dashboard got smaller and it got faster, in that order.