Building analytics dashboards

Build it as a structured project — components, hooks, and helpers in separate files, not one giant file. Hand-rolled SVG is fine, often better than a chart library for bespoke interactions.

A dashboard answers questions; it isn't a page of charts. Its dimensions (time plus the data's categorical axes) are the product: make every one filterable, cross-linked, and honest about what it can't show.

For the visual identity — type, palette, spacing, and polish — use the frontend-design skill, and ask the user for brand guidelines or a reference if the direction isn't clear. This skill covers only what's specific to data and dashboards: pipeline, interaction, and visualization.

Data pipeline

• Refresh on a schedule, and let users trigger a refresh on demand — debounce/lock it so concurrent loads don't stampede the source. Put the schedule on one entry point that fans out to the fetchers, so cadence lives in one place.
• Fetch incrementally: pull only what's new since the last stored point, but keep a full-backfill path for a cold or empty store.
• Retry transient source failures with backoff, and never overwrite good data with an empty or failed result — a bad fetch leaves the last good data in place.
• Store raw source data under a stable schema and derive everything at read time, so display changes don't force a re-fetch. Store the inputs to a transform, not its output — keep the mapping (e.g. a lookup table) and apply it live, rather than baking mapped values into storage. Keep enough history to backfill or re-derive when the source or your schema changes.
• Aggregate on the fly, but when the raw volume is too large to load and roll up per request, push the aggregation to the source API (query it for pre-summarized data) or precompute rollups on fetch.
• Let users download the data (e.g. CSV): the processed rows behind the current view (respecting active filters, for finance/reporting) and/or the raw records (for their own analysis).

Everything is a filter, selection is shared