Pulse: engineering analytics platform

Pulse is an engineering-analytics platform built at Studio Graphene. It pulls Jira and GitHub activity into live dashboards: delivery metrics, review health, sprint progress and per-project breakdowns that delivery teams check every day. I am the sole frontend engineer on the product.

As the data volume and the number of views grew, the frontend got slower exactly where people used it most. Moving between a metric and its breakdown re-fired API calls for data the app already had, and broadly shared state meant a change in one place re-rendered components that had nothing to do with it.

There was a second, quieter problem: non-technical stakeholders couldn't self-serve. Getting a number out of Pulse meant asking an engineer to pull it.

Profiling pointed at the data layer before the components. The query cache was tuned aggressively for freshness: very short staleness windows plus refetch-on-mount meant shared queries re-fetched on almost every navigation, even though the cache already held the answer. Once that pattern was visible, the re-render problem turned out to have the same shape: state was shared far more widely than it was actually read.

I introduced per-query staleness windows matched to how often each kind of data actually changes. Reference data that changes rarely is now served from cache for minutes rather than milliseconds, so navigating between views stopped re-firing the same requests.

On the render side, I split the widest contexts so each view subscribes only to the state it reads, and added targeted memoisation to the heaviest components. The rule I held to: make the cheap path the default path, and write down every exception.

On top of the faster dashboard I built Pulse AI, a natural-language query layer over the same metrics. A project manager can ask for a metric in plain English and get the answer directly, instead of learning where it lives in the dashboard.

Caching and context splitting add real complexity. A staleness window is a product decision as much as a technical one: you are choosing how out-of-date each kind of data is allowed to be. Cache invalidation and a more fragmented state tree are genuinely harder to reason about than fetch-on-render. I accepted that overhead because the responsiveness gains were measurable and the dashboard is used every day.

Redundant API calls dropped by roughly half and re-renders by around 45%, so the dashboard stays responsive at the data volumes that used to hurt it. Pulse AI gave non-technical stakeholders self-serve access to project and developer insights without writing a single query.

Prefetching the breakdown a user is most likely to open next, request deduplication at the route level, and performance budgets in CI so regressions get caught before anyone feels them.