The Dashboard · Case Study

Business challenge

Different clients kept asking the same question on separate calls: where is all our operations data, in one place and in real time? Nothing answered it. No brief, no champion, no one assigned to build it.

My authority

Originated the product and led all four rebuilds: solo through Phase 1, then leading the team I built from Phase 2 on. The hire case, each rebuild case, and the configurator case were mine to make, and to make again until they were approved.

Scale

Deployed across banking, smart cities, critical infrastructure, and industrial. Dozens of client deployments.

Outcome

From Phase 2 it sold on its own momentum, and became the highest-earning recurring product in the company's history. Still in production. Still selling.

More context Collapse context

My role UI/UX Designer → Senior UI/UX Designer → Team Lead across the four phases · UX architecture and product strategy · front-end direction · technology evaluation · team building.

Team Grew from solo (the entire UX function) to a team of 4: a graphic designer and two front-end developers, developed into independent contributors through the work.

Stakeholders CTO (my direct reporting line) · CEO · engineering and database leads · enterprise clients: IPPL, AnG India, Manappuram Finance, Varanasi Smart City.

Duration ~24 months of active design across 4 phases · Phase 1: Mid-2015 · Phase 2: 2016 · Phase 3: Late 2017 · Phase 4: 2020 · still live in production today.

Scope at peak 500+ pages live · 700+ widget types in the catalogue · all from a single codebase.

Revenue impact ₹27–28L / month recurring at exit · originated, not inherited.

Overview

It came from a recurring question.

A business intelligence platform built for executives, managers, and administrators: people who needed to understand what was happening across their operations, not process individual incidents.

The data existed; getting at it did not. To see alert volumes, response times, or site performance, executives had to ask a database team, or Intellve, to pull the numbers from the database manually and send them back as spreadsheets. No self-service view existed anywhere in the product. Independently of one another, client after client kept asking the same passing question, and I read the pattern as a product gap, not a feature request.

What I built scaled across banking, smart cities, critical infrastructure, and industrial clients from one configurable codebase: different industries, different data, one product. That reach is why it became, and remains, the company's highest-earning recurring product.

The team grew with each phase: from solo, the entire UX function, to a four-person team by the web phase, each developed into an independent contributor through the work.

Leadership signal

Originating a product line from a recurring client question, not a brief, is the reflex that separates a leader from a contributor. The Dashboard had no champion in the room until I treated the question as one.

Executive Summary

Built from a question clients kept asking, with no brief behind it, it became the company's highest-earning recurring product.

Dashboard Phase 4, configurator with widget library — Phase 04 · A dashboard configured without engineering: the AnG India deployment, co-branded and Powered by Intellve, in light mode

700+

Widget types in catalogue

Configured, not coded

A dashboard assembled straight from the widget catalogue, no engineering involved: the AnG India deployment, co-branded and Powered by Intellve, in light mode.

Evolution

Four phases. Four rebuilds.

Each was a complete architectural rebuild triggered by a specific limitation the previous version could not overcome.

01

Phase 1 · Mid-2015

Charts in TouchControl

Embedded reporting proved market demand existed before a product did.

Lived inside operator software, not accessible to executives.

02

Phase 2 · 2016

Standalone WPF desktop

Separation created a standalone product for a different audience entirely.

Windows-only. No browser, no mobile, no remote access.

03

Phase 3 · Late 2017

Web application

Web architecture dissolved the installation barrier, access from anywhere, by anyone.

5–7 day dev cycle per client-requested change.

04

Phase 4 · 2020

Configurator + widget library

Configuration shifted from a development task to a client self-service capability.

Live in production. 700+ widgets. Zero-day config.

Eight charts inside operator software.

Built

Analytics section inside TouchControl

Key call

Fastest path, no new infrastructure, demand proven first

Ceiling

Required operator-grade software just to view, with no export

Observed

Executives and managers at multiple client organisations needed aggregate visibility: alert volumes, response times, site performance. The data existed. There was no way to access it without requesting reports manually from a database team or asking Intellve to generate spreadsheets. No self-service visibility existed anywhere in the product ecosystem.

Built

A dedicated analytics section inside the company's monitoring software: a few charts showing alert counts, severity distributions, and category breakdowns. This grew to seven to eight chart views as clients engaged and generated new ideas. View-only: no export, no table view, no download. Print-screen was the only way to share what was on screen.

Key decisions

01

Built inside the existing software first.

Fastest path to something clients could react to: no new application, no new infrastructure, no procurement cycle. Separation could come once demand was established.

02

Used the available charting library.

Limited in chart types and customisation, but it needed no procurement, no approval, no distribution limits, and no licence expiry or renewal. Shipping something clients could react to was the priority; a better library could be evaluated once the concept proved itself.

The ceiling

To see the charts at all, an executive had to install the full operator-grade software, a setup built for a different job entirely. And even then the data was locked to the screen, with no way to take it out and work with it. It needed its own home, built for them.

Executive Summary

Proof of demand, not a product: eight charts, no brief, just a question clients kept asking. Enough to justify starting.

Dashboard Phase 1, charts embedded in TouchControl — Phase 01 · Alert analytics embedded inside TouchControl operator software

Embedded analytics

The first version lived inside TouchControl: a handful of charts for alert counts, severity, and category breakdowns. Enough to prove clients wanted it, but trapped inside software built for operators.

A new product for a different audience.

Built

Standalone WPF desktop application

Key call

Priced and sold on its own, not a platform feature

Ceiling

Windows-only, no browser, no mobile, no remote access.

Observed

Phase 1 proved the concept: clients understood the value and wanted more. But the analytics stayed buried inside operator-grade monitoring software the executives it was for were never meant to run. A dedicated product, for a different audience with different needs, had to exist on its own.

Built

This became its own product: a standalone Windows desktop application, cut free from the monitoring platform, with its own design system, navigation, and installer. The colour scheme went light, built for offices and boardrooms rather than the dark control rooms operators work in, and that call was right. It carried richer charts than Phase 1 and, for the first time, let people take the data with them: export to PDF or image, a click-through table of the underlying records, and a full download. Deployed first at Varanasi Smart City, then Manappuram Finance, it began selling consistently from here.

The desktop was a fallback, not the plan. Web was the intent from the start, but the developers hired to build it in Angular were pulled onto a ticketing system a paying client needed immediately, a call made above me. With no core web developer left, I shipped on WPF: the backend team already ran it, I had built WPF screens myself, and I moved my two front-end designers onto its markup so we could deliver with the capacity we had.

The graphic designer who joined for this phase was a hire I proposed to management with a specific case: what the role would own, how it would free capacity for higher-value design work, and what the team would produce differently. Proposing the hire before being asked to hire is a leadership-level reflex, not a design one.

Leadership signal

I made the hire case myself, proposed to management with a written brief: what the role would own, how it would free design capacity, what the team would produce differently. Most designers ask to hire. Leaders pitch the business case before asking.

Key decisions

01

Standalone application.

Two different audiences needed two different products. Separating the Dashboard meant it could be priced, sold, and deployed independently of the monitoring platform ecosystem.

02

Light mode over visual consistency.

Every other product in the suite used dark mode, suited to operators in dimly-lit control rooms. Executives in offices and boardrooms needed something different. Context over consistency.

03

LiveCharts, after licence audit.

Validated perpetual licensing, no user limits, no distribution restrictions, non-negotiable given how the software was deployed. Chose for fit, not familiarity.

04

Modular project architecture.

Each page a self-contained component, widgets as reusable elements, a clean folder structure: the same modular approach from the TouchConfig rebuild, carried across every product.

The ceiling

Being a WPF desktop application, it was Windows-only and bound to each machine it was installed on, the opposite of device-agnostic. An executive had to be at that specific desktop to use it: no browser, no mobile, no access from wherever they happened to be. Clients had asked for exactly that. The product had to leave the desktop.

Executive Summary

So it became a product of its own: a standalone application for the executives who wanted it, priced and sold independently, the first version to earn money directly. But it lived on the Windows desktop, and that desktop was about to become the wall.

Dashboard Phase 2, standalone consolidated KPI dashboard — Phase 02 · The standalone dashboard, a consolidated KPI surface pulled out of the operator software

Standalone, light-mode

The dashboard pulled out into its own application, with a light interface built for offices instead of control rooms: richer charts, and for the first time, data you could export, table, and download.

The web version. Device-agnostic.

Built

Web application, role-based access, sharable dashboard pages

Key call

Open web standards, so a small team could ship and maintain it

Ceiling

5-7 day dev cycle for every client-requested change

Observed

The desktop version was selling well, but the requests all pointed one way: access from any device, with no install. Executives on non-Windows machines, managers wanting it on mobile, IT teams slow to deploy. I had been pushing for the web since Phase 2. Now it was time to build it.

Built

A full web rebuild on a completely new technology stack: any browser, any device, no installation. The light-mode design system from Phase 2 carried over, adapted to the browser. It added role-based, per-user access control and sharable dashboard pages, with the pages customised per client (clients in the same domain needed little). amCharts replaced LiveCharts after the same licence check as Phase 2: perpetual terms, no user limits, no distribution restrictions.

Key decisions

01

HTML/CSS/JS over a framework.

A framework like Angular would have been the textbook choice, but the developers I had for the build were freshers, not yet framework-capable. Plain HTML, CSS, and JavaScript was the right call for the team and timeline I had, even though it set the ceiling we would later hit.

02

amCharts for web-native charting library.

Evaluated on the same criteria used for LiveCharts in Phase 2: perpetual licensing, no user limits, no distribution restrictions. Chosen for fit with the web environment and licence terms, not familiarity. Non-negotiable given how the software was deployed.

03

Responsive by default.

Building on web standards meant the dashboard adapted to any screen, from small laptops to tablets to phones, with no separate build. It cost nothing extra and removed an entire category of future requests before they arrived.

04

Same modular architecture carried forward.

The same modular philosophy as Phase 2, for cleaner code and easier project management, carried into Phase 3. Each page a self-contained component, widgets as reusable elements, a clean folder structure. The codebase could be extended without its original architect present. Continuity here was a deliberate choice, not a default.

05

Cross-team alignment before development began.

Before development started, the complete web architecture was presented in a full-day session with cross-team leads and managers. Every question answered, every constraint surfaced, everyone signed off before a single line was written. This was already how I ran every major delivery, the ones before this and the ones after.

06

Building delivery capability in the team.

Two developers, both freshers, were assigned to me to build Phase 3. Even while it was underway, they were repeatedly pulled onto regular development tasks. Neither could deliver independently yet. So before asking them to build, I laid the groundwork: study time, sample code, structured preparation. By launch, both were handling requirements on their own, without backend involvement. The team that shipped Phase 3 wasn't inherited ready. It was prepared.

Diagnosis over decoration

A few months after the web Dashboard went live, a senior executive at IPPL, a major critical-infrastructure client, said he did not like the dashboard. The project-management team on the account read it as a design complaint and asked for fixes, spacing, font sizes, a few visual changes, which my team made on my direction. He was still dissatisfied.

So I took it to a call with that team, my team, and leads from development, delivery, and testing, and worked through it by questioning, such as: what he did not like the moment he logged in to the dashboard, rather than simply what he disliked about it. The conclusion was that the look and feel were fine. The data and the widgets he needed already existed, but they sat scattered across pages, never brought together into one view where everything behind a decision lived in one place. What was missing was cohesion.

The fix was an information-architecture reorganisation, co-locating the related, decision-critical data so the full picture sat in front of him at once. The complaint disappeared without a single visual change. Hearing the real requirement behind an inarticulate one is diagnosis, not decoration.

The ceiling

Every client-requested change, a new chart, a layout adjustment, a label update, required a full development lifecycle: design, development, regression testing with a dedicated tester for 5 to 7 days, deployment, and client verification. Across 28 to 34 active client deployments, maintenance was eating the team.

Executive Summary

The web rebuild broke the desktop wall: reachable from any browser, any device, no install. But every client change, even a label, now meant a full build and redeploy, and across dozens of deployments that was crushing the team. The work had to move to the client.

Dashboard Phase 3, browser-based dashboard with live map — Phase 03 · The web rebuild, live KPIs and a map-based view, reachable from any browser

On the web

The rebuild in the browser: live KPIs and a map-based view, reachable from any device with no install. The light-mode system from the desktop version carried over, now adapted to the web.

From fixed pages to self-service.

Built

Configurator: clients build their own pages and subpages from 700+ widgets

Key call

Self-initiated to solve an internal cost, not a client request

Outcome

7-8 day change cycle dropped to zero for config-level changes

Observed

Every change to the Dashboard came through me: I had originated it and owned it, so every correction and new requirement crossed my desk, and each time the same full cycle repeated, design, development, database update, 5 to 7 days of regression testing, deployment, client downtime. For our largest client it had grown to 180 to 200 pages, and maintenance was consuming more of the delivery and testing teams than new work did. No client had raised it. I put the cost in front of cross-team leads, management, and stakeholders, and the plan was approved at once.

Built

A semi-configurable platform: a library of 700 to 800 pre-built widgets, categorised and searchable by industry and data type, on a configurable page grid. From it, clients and delivery teams could build as many dashboard pages and subpages as they needed, composed from existing widgets in hours, not days. No development, no redeploy.

Leadership signal

Because I owned the Dashboard, the cost surfaced through me before it reached anyone else, and fixing it meant winning a purely internal case, the hardest kind, with nothing client-facing to point to. I made that case across the teams, secured approval, and delivered the platform with two developers. Seeing a systemic problem early and committing the company to solve it is what ownership is actually for.

Key decisions

01

Semi-configurable over fully dynamic.

A fully dynamic builder needs a large, dedicated engineering team. For the build I had two developers assigned to me, both freshers, pulled onto other live work whenever it came in. So the call was a catalogue of 700+ pre-built widgets covering every chart type and industry use case: everything a real client needed, built within the capacity we actually had.

02

Database naming convention standardisation.

Beneath the configurator sat one rule for how every system named and structured its data. Any system that followed it plugged straight into the existing widgets, so a client could add a new data source and see it on their dashboard with no developer involved, the quiet foundation everything above it depended on.

03

A widget catalogue now, the builder on the roadmap.

Pre-built widgets carried our domain knowledge: industry defaults, sensible labels, validated colour mappings, a sound chart rather than a blank canvas to get wrong. A fully dynamic widget creator, where a client connects a data source and builds their own, was on the roadmap and the path to a 100% configurable product, but it needed engineering we did not have. The catalogue was the right call for the resources, and valuable on its own.

04

Free upgrades for all existing clients.

No charge for Phase 4 migration on any deployment. The strategy: real-world testing across every live environment, one version to support instead of many, and goodwill across all 28 to 34 clients.

05

First Flutter application in the ecosystem.

A client's executives wanted the dashboard on their phones: one tap to it, no browser, no URL, no login every time. They asked for Android and iOS apps; the platform call was mine. Working the options through with the developers, including the one maintaining the existing apps, I chose Flutter, one codebase for both systems. It was the company's first Flutter project. I gave my front-end designers and developers the time and direction to learn it; they built the front end and backend, and the company moved all its app development to Flutter from there.

06

Co-branding over full white-labelling.

A major client wanted Intellve's branding gone entirely. I made the case against it on product strategy: software carrying only the client's logo makes Intellve invisible to that client's own customers, eroding the brand equity behind every future deal. The counter-proposal kept the client's identity at the top and Intellve's in the left-nav footer, made effortless by a self-service logo page, and the model was extended across every product.

The outcome

Change cycle: 7–8 days → 1 day for delivery teams, zero for configuration-level changes, with regression testing eliminated for the most common change. Multiplied across 28 to 34 deployments, that is the cost the company stopped paying. Architecture still in production today.

Executive Summary

The configurator moved the work to the client: they build and change their own pages from 700+ widgets, with no developer and no redeploy. The change cycle that was crushing the team collapsed to nothing, and the product became self-sufficient, the most commercially durable form the Dashboard ever took, still in production today.

700+

Widget types in catalogue

Configured, not coded

A dashboard assembled straight from the widget catalogue, no engineering involved: the AnG India deployment, co-branded and Powered by Intellve, in light mode.

Impact

Highest-earning product. Still selling.

₹27–28 L

Recurring revenue / month

The run-rate the product reached across its client base at exit, with one distributor making up more than half.

700 +

Widget types in catalogue

Categorised by industry and data type. Searchable across four facets.

500 +

Pages live in production

Estimated once during support work, across banking, smart cities, industrial, and critical national infrastructure. Clients add their own pages, so the count only grows.

9.5 yrs

In continuous production

Live and paid for as recurring revenue the whole time. New sales still come on top, each one more MRR.

7 → 0 days

Change cycle

From a 7 to 8 day full development cycle before Phase 4 to zero after for configuration-level changes, saving that cost across every deployment.

Why it kept selling

Operator software is bought by executives for someone else. The Dashboard was bought by executives for themselves.

It gave them what they needed to run the business: live numbers, history, and patterns in one place, no friction and no waiting on anyone to pull a report, which kept their operation legible and their decisions fast. The person getting that value was usually the person approving the purchase, so procurement compressed and price stopped being the question. That was my read on why it sold the way it did.

Published client outcomes

In their own words.

There has been natural adoption of the platform with no training whatsoever. We saw the benefit of integrating Intellve's platform with ours, and it improved the efficiency of our company as a whole.

Rithesh, Senior Manager · IBMS Mumbai, K Raheja Corp

Implementing their software helped us make our command centre more effective.

Aneesh Menon, DGM Security · Manappuram Finance

Intellve helped set up two fully operational command and control centres that play a pivotal role in managing day-to-day security operations, with critical alerts.

R. Gopiram, DGM (Inst.) · MRPL (ONGC)

The management layer of a system that paid for itself

At Manappuram Finance, the system was publicly credited with around ₹100 crore a year in savings, a 40% cut in insurance premiums included in that figure.

The Dashboard was the management layer of that system: a branch risk-rating model built from historical alert data, showing which of 3,500+ branches carried the most alerts, the most severe incidents, the most device failures, and informing where cameras, fortification, and police coordination went next.

What changed structurally

Before and after.

Before

After

Even the smallest change ran the full development lifecycle: meetings, understanding the requirement, design, development, testing, delivery, deployment.

Clients make configuration-level changes themselves, instantly, with no development cycle and nothing for us to ship.

Mobile strategy: none. Each new platform was a separate engineering decision from scratch.

The first Flutter app, built for one client's Dashboard, became the foundation for all the company's mobile development.

A separate version to support for every client, fragmenting across 28 to 34 live deployments.

Free upgrades consolidated every client onto one supported version, tested against every real environment.

Constraints

The limits I built against.

The dynamic builder I scoped out.

A fully dynamic, client-facing builder was buildable, but it needed a larger team and more resources than I had. So I built what the team I actually had could ship and keep maintained: a 700-widget catalogue, organised by industry and searchable. That call shipped the product and kept it alive years past launch.

The limit it left is that a genuinely new widget type still has to come from us. The client-facing builder that removes that last dependency is sellable independence, not a someday item, so next time I'd carve capacity toward it earlier rather than treat it as the step after everything else.

The cost case I made too late.

I saw the maintenance cost of supporting a separate version for every client coming before I made the formal case, and I let the evidence pile up until the pain was undeniable rather than forcing the decision while I was still the only one who could see it.

At this level, spotting the problem is the easy half. Forcing the decision on your own timeline, before the cost becomes everyone's problem, is the half I've worked hardest to sharpen since.

The cost of every rebuild.

Each phase was a full rebuild, which meant running two products at once: supporting the live version while the next was built and tested. Four phases meant four of those parallel-maintenance stretches, each a real load on a small team.

The modular architecture I carried across phases is what kept it survivable, since each rebuild reused structure instead of starting clean. The lesson I hold is that the architecture has to be designed for the transition, not only the destination, because most of a rebuild's cost is the months you spend supporting both.

The framework I lost the team for.

Angular was planned for the web rebuild and developers were hired for it. Before Phase 3 began, they were reassigned to another product, a call that was not mine to make, and I built the web Dashboard in plain HTML, CSS, and JavaScript instead.

The constraint worked out: plain web carried less overhead than the framework would have for what the product needed, and it shipped on time. The lesson is to design the architecture so it does not depend on a team you have only been promised, because the staffing you are counting on is the first thing reassigned when priorities shift.

The Dashboard.

It came from a recurring question.

Four phases. Four rebuilds.

Four phases. Four rebuilds.

Eight charts inside operator software.

Observed

Built

Key decisions

The ceiling

A new product for a different audience.

Observed

Built

Key decisions

The ceiling

The web version. Device-agnostic.

Observed

Built

Key decisions

Diagnosis over decoration

The ceiling

From fixed pages to self-service.

Observed

Built

Key decisions

The outcome

Highest-earning product. Still selling.

Why it kept selling

In their own words.

The management layer of a system that paid for itself

Before and after.

The limits I built against.

The dynamic builder I scoped out.

The cost case I made too late.

The cost of every rebuild.

The framework I lost the team for.

The product decision only a leader makes.