Reducing uptime by 20x using a Framework-level feature


While working with an industry-leading SaaS analytics company, our technical team was asked to build data visualization charts & reports. The primary approach was to develop & extend a UI framework consisting of reusable config-driven components.

As the product’s clientele grew, data volumes increased exponentially. Case in point – one of the customers was facing very high loading times (up to 40s+). There were proposals to improve loading performance by working on low-hanging solutions like optimizing the database by building sub-set views, making concurrent data queries, etc.

However, our technical team was convinced that a future-proof, scalable & extensible solution was needed at an architectural level. Such an extensive solution required sponsorship for the significant development and planning effort necessary.  Since there was no official request for such a solution, this foresight first needed to be communicated, and consensus needed to be built with the client.

This was not only a critical technical challenge but also needed ownership in building consensus by educating everybody about the need and the impact.


A technical solution was proposed to build a framework-level feature for different reports, dashboards, and customers. A framework solution would not only solve this instance but a solution for this pattern across the entire platform. The aim was to make functionality and usage independent of the data contained in each component.

Few key behavior flags could be configured in the backend, and each configuration would impact its behavior. The solution would cater to multiple data sources and return different data types of various sizes. It would be primarily decoupled with other platform features and driven by explicit configurations. Such a solution would be scalable in the future as the data sizes would vary mainly between different types of clients.

The design ensured that the complex logical data processing was done at the server end and not at the front end, making the front end really snappy, even for large datasets. The front end would become more responsive and performant, positively impacting usability and adoption.

Once a technical solution was found, to build consensus, we took ownership to explain the repercussions of this problem growing in the future in all areas of the product. Multiple teams need to be convinced of such a significant architectural upgrade. As product management teams managed the roadmap, convincing them that the architectural change was worth the effort was also necessary. We needed to enroll these non-tech stakeholders in a future-proof technical proposal, which wasn’t easy.

During implementation, given multiple teams required to coordinate, we proposed a preliminary design and got it reviewed, and took inputs from each one of them. Later, we developed a detailed development rollout plan,  communicated it to all stakeholders, and got it approved by them.


Improved User Experience (UX) by speeding up data loads significantly. In some cases, it resulted in 20x improvement, reducing page load times from 42 seconds to 2 seconds.

Reduced server-side power consumption by minimizing the size of data being fetched for each request.

Increased configurability drastically, thereby impacting customer-specific customization significantly.

Any implementation could pull data from multiple sources of different types & structures, and the component would just work out of the box.

“I am proud of Measured’s strong culture, thus one of my chief concerns during our expansion is a dilution of that sense of community. Akrity has assuaged my concerns through their own commitment to community and has worked lockstep with Measured to keep ours strong. Akrity’s technical ability and skill has not only supported our endeavors but has helped us push out key features that have measuredly grown our position in the market.”

Jared Scott

Director, Engineering, Measured