PORTFOLIO/01/Bellwether

2 screens · click to open live

B2B analytics at organisation scale from prototype to platform

I took a working B2B analytics prototype whose business logic lived largely in the browser and turned it into a backend-driven platform serving two dozen client organisations and data from a mobile app with 20,000 users. Over the course of a year, I designed and built the domain model, query layer, multi-tenant access control, and caching architecture, with the central challenge being how to make increasingly complex hierarchical analytics fast enough to operate at organisational scale.

The product was intentionally different from a conventional dashboard. Rather than presenting clients with a wall of charts, it turned raw activity into a small set of actionable statements, deriving figures across global, country, organisation, and individual levels. Almost nothing displayed was stored, so each view depended on calculations against the underlying data.

As the platform grew, that approach exposed a performance problem that could not be solved simply by reducing the number of queries. An organisation view could execute around twenty of them, often repeating work that had already been performed elsewhere, yet even after reducing the query count the page could still take three to five minutes to assemble. The real cost was the aggregation itself, and because the data only needed to be a day old, there was little reason to perform that work while a user was waiting for a page to load.

I moved the calculations into a nightly processing pipeline that built the hierarchy once, from the top down, allowing each level to reuse the work already completed above it. The query layer then used the structure of each query as its cache key, so queries sharing a prefix could reuse the same cached work instead of recomputing the same aggregation independently.

This changed the architecture from a collection of expensive page-level calculations into a common calculation chain that could support organisation, global, and individual views alike. Pages that had previously taken several minutes to assemble now loaded in under three seconds.

I was the lead engineer on a two-person team, owning the technical design, backend, and frontend architecture while my manager continued to set product direction and we shared interface design. The result was not simply a faster application, but a backend that could support the product’s analytical model without pushing its computational cost onto every user request.

ROLE

Lead Engineer · Two-person team · One year

Backend architecture, data layer, caching and access control. Front-end structure, components, and part of the interface design.

  • An aggregate over the whole population, a ranked list under it, and one entity broken into the signals behind its score. Three levels of the same data, all wanted on one screen, and in the naive version each one is its own query.

  • The weights and the cut as configuration rather than code. Moving the threshold changes the population it selects, so the sweep beside it shows what each cut would flag before you commit to one.

Reference implementation. The original is under NDA.