The Dashboard.

The problem

The people accountable for entire operations, branch managers, security heads, plant administrators, and the executives above them, had no live view of how those operations were running. They did not need individual alerts or events; they needed what those alerts or events added up to: incidents week over week, which sites ran hottest, whether response times were improving, whether equipment was failing in particular zones.

Every number sat in the system, but reaching it meant asking Intellve or an internal IT team to export it into a spreadsheet, which was slow, never real-time, unworkable at volume, and had no analysis of its own. The same question kept coming from clients who had never spoken to each other, and that is what marked it as a product gap, not a one-off request.

Research

I had never built a dashboard at this scale. Before and as I built the first version, I studied how the established business-intelligence tools, Tableau and Power BI, were structured, to understand how this kind of product is actually made.

Constraints

There was no budget for new tools, no design team, and no front-end developer free for new-product work. The only charting available inside our WPF framework was the toolkit's built-in set, limited and unable to export, on a technology I was still learning. Whatever proved the idea had to be built inside what already existed, by me, with what was already paid for.

Built

A Dashboard section inside TouchControl, opening to screens of aggregate alert data: total counts, open against closed, severity distribution, category breakdowns, and average resolution timing. I owned the product and its front-end direction while the development team built the data layer, a division of work that held across every phase. Clients used it immediately, and 7 to 8 more screens followed as they asked for more.

Key decisions

Outcome

It proved something the company did not yet know for certain: clients wanted this enough to keep asking for more of it. That was the mandate to build it properly.

The trigger

Phase 1 had proved the demand and shown the limit in the same breath: the charts were trapped inside operator software, on operator hardware, with no way out to a meeting. The Dashboard had to become a product of its own, built for people who would never sit at a control-room console.

Constraints

Web was the right next step, and the call to go there was mine. I pitched it, and cross-team and management agreed: an Angular stack was locked and 2 Angular developers were hired for the build. Before it began, both were pulled onto an urgent paying project, the SLA and ticketing system. With no web developers left, I built the next version as a standalone WPF desktop application instead. It was a fallback, but it solved the immediate problems anyway: charts you could export, no operator-grade hardware, and no need to install the full operator platform just to see a dashboard.

Research

The users were not operators in dark control rooms. They were executives in well-lit offices and managers presenting on projectors, and that context pointed straight at a different design system.

For charting, I evaluated LiveCharts on capability and licence together: capable, actively maintained, broad in chart types, and clean on terms, perpetual use, no user limits, no distribution restriction.

Built

A standalone WPF desktop product on its own light-mode design system: a light palette, larger type tuned for reading rather than scanning, a layout built for presentation, and charts that could finally be exported, tabled, and downloaded. It deliberately broke visual consistency with the rest of the suite, because the suite was built for a different person in a different room.

Key decisions

Outcome

The Dashboard now stood on its own, sold and priced as a product, and from here it sold alongside every major project the company took on.

The trigger

The standalone product was selling, but the Windows install was the last friction between an executive and their data, and clients were now asking for the browser and the phone by name. The Dashboard had to leave the desktop.

Constraints

By now my team had grown. I had 2 front-end developers, and 2 freshers from the development team, hired as back-end developers and assigned to me. The freshers had no framework experience, no Angular, no React. Rather than stall, I gave them time to ramp up and we planned the web build on plain HTML, CSS, and JavaScript with the charting library, a stack they could own and learn on. They did, growing into independent developers over the project, even as they were periodically pulled back for the development team's own work: Angular bug fixes, small WPF tasks, ticket work.

Research

I evaluated the web charting libraries before committing and chose amCharts, judged the same way as before, capability and licence together: a vast chart catalogue, deep customisation, live refresh, full export to PDF, PNG, and CSV, on a perpetual licence that matched how we distributed.

Built

We rebuilt the Dashboard as a browser application in plain HTML, CSS, and JavaScript, my front-end team on the interface and the backend and database engineers on the data layer, all aligned before a line was written. I structured it the way I had structured TouchConfig: each page a self-contained module in its own folder, widgets as reusable components callable in 2 or 3 lines from a shared library, a structure any developer could navigate without asking me, and adding a page touched no other page. Alongside it, a Flutter mobile app, the company's first, put the executive view on phones, one tap to the overview for the people who needed the numbers away from a desk.

Key decisions

Outcome

On the web, anyone with a browser could open the Dashboard, no install, no hardware. Adoption widened sharply inside client organisations, and it became the most-sold and most-loved product across the client base.

A diagnostic moment

For weeks during the IPPL engagement the feedback came back through project managers: the executive does not like the dashboard, with no one able to say what was wrong. I asked for one call with him directly. For the first 15 minutes I asked only about visual things, colour, type, spacing, density, and he objected to none of them. So I said, with everyone present, everything I have asked about is how this looks, and you have raised no concern; what I am hearing underneath is that you open a page and cannot find what you need to decide. He said yes, exactly that. He had blamed the most visible thing, when the real problem, the information architecture, was not in his vocabulary to name. We rebuilt the pages around his decisions, and the complaints stopped.

The trigger

No client asked for this. Clients were satisfied; nobody was complaining about change cycles or timelines. The problem was inside the company: 5 to 7 days of regression testing per change, 1 to 2 of deployment, several people across teams for what should have been hours of work, and a cost that would multiply as the client base grew.

Constraints

A fully configurable business intelligence platform needs a large team and a long runway, and we had neither: my team on design and front-end, 2 developers on the build, all on limited capacity. The investment had no client asking for it and no external metric to validate it, the hardest kind of work to get backed.

Research

I went back to the competition, this time for the configurable question specifically, and added Zoho to the study of Tableau and Power BI: how web-based, client-configurable dashboards are actually built. They had all solved it, but with dedicated teams of hundreds, which proved the problem was real and solvable, not a niche internal quirk. That told me a fully dynamic builder was out of reach with the resources we had, and that a middle path, pre-built widgets on configurable pages, was the right architecture for the team and timeline we had. We planned it together, and I took the case to cross-team and management for approval.

Built

Roughly 700 to 800 pre-designed, pre-tested widgets covering every chart type, data category, and domain use case we had met or could anticipate, across BFSI, smart city, critical infrastructure, and industrial. Clients built their own pages: name a page, choose a filter, browse the library, place and resize widgets, save, and share view-only links, with sub-pages under any page.

Behind it sat one standardised database naming convention the database team and I defined and documented as a formal specification. Data stored in tables that followed the convention flowed into the right widget with no development at all. The system imposed no rules on naming or layout, and every client still organised theirs logically without being forced to.

Key decisions

The outcome

The change cycle that had taken 5 to 7 days dropped to 1 for delivery-team changes, and for configuration-level changes, adding a widget, adjusting a layout, creating a page, development and testing left the process entirely. When clients made those changes themselves, the cost to us was zero. The cost of running the Dashboard business fell sharply while its commercial performance kept growing, with no proportional growth in overhead.