Case Study 02/04

MonitoringHub.

A revenue problem given a name, a market seen first-hand, and the subscription monitoring product that grew from both: the company's entry into a segment its enterprise business could never reach.

Business challenge
New owners pressing for growth, on revenue that was project-bound and could not compound.
My authority
Named the revenue problem, ran the field research, shaped the product, and directed the build.
Scale
A market the enterprise model never reached: SMEs, retail, schools, housing societies, and SI networks.
Outcome
The company's first cloud SaaS, a new business model in a new market, still live and earning.
More context Collapse context
My role Senior UI/UX Designer to Senior Team Lead, across conception, launch, and maturation.
Team My UX core, plus a managed design agency, a Flutter team, and the development team.
Stakeholders The management team, the CTO, the CEO, and sales.
Duration About 14 months from the leadership session to first release, then iterated through 2025.
Scope at peak Multi-tenant SaaS: SMEs, schools, societies, and single owners with 50+ operators across thousands of devices.
Revenue impact ₹7–8L a month recurring at exit, and ₹11–12L since, per former colleagues.
Overview

The first SaaS business model.

How a business decision, not a design brief, opened a market the company had never reached.

MonitoringHub opened a new market with a new audience: small businesses, schools, housing societies, retail chains, and the system integrators that served them. A decade of enterprise-grade integration expertise, rebuilt as a web-based SaaS subscription anyone with a camera and a connection could buy.

At its core is the ecosystem's defining capability: any IoT device, any make or brand, cameras, sensors, intrusion, access control, fire, plugs into one platform and talks to the rest. Owners juggling a separate app per device brand got one integrated product instead, with alerts, device health, reports, and a built-in configurator on top, the same product a single owner runs from a phone and a multi-site organisation runs from a control room.

It was a business-model decision before it was a product brief. Across a run of leadership sessions where the owners kept pressing on how the company could grow, this was one of several proposals, and the one that won. The product that delivered it reached first release in 14 months.

Leadership signal
The work here began as a business question, not a design task: naming why the company was not growing, and proposing the model that answered it, before a single screen existed. Reading the commercial problem first is what made it the right product to build.
Executive Summary
A business decision before a product brief: the company's first cloud SaaS, in a segment the enterprise business could never reach. Shipped in 14 months, earning still.
MonitoringHub mobile app: a dashboard showing system health and device, shop, camera and alert counts, plus a per-site monitoring schedule with day and time controls.
The product in a pocket

The same platform a control room runs on the web is what a single owner carries on a phone: system health, device and site counts, and per-shop monitoring schedules. One product, every screen size.

The problem

Digging wells versus a river.

The products were strong and the clients were happy. The problem was the revenue: it stopped the day a project closed.

Cash that stopped flowing.

Before COVID, the new owners kept asking the same question: why was the company not growing faster? The products were strong and the clients satisfied, but the revenue was project-dependent, a new well dug for each engagement and drunk dry when it closed. A straightforward sale took 5 to 6 months, a large one took years. Profitable, but it could not compound. The Dashboard had added recurring income, but only from enterprise clients.

The framing that won the room

"Projects are wells. You dig, you drink, it runs dry, and you go find the next place to dig. A subscription is a river. The level rises and falls, but it rarely stops flowing."

The new owners had come from outside technology. A spreadsheet would not have moved them; a picture they could repeat to one another did. Winning a business-model decision is often a problem of language before it is a problem of logic.

A market no one had visited.

Beneath the revenue problem sat a reach problem. The growth the new owners wanted lived in a market the company had never served: the small shops, clinics, retailers, schools, and housing societies that make up most of the country. The enterprise products were built and priced for command centres and large deployments, far beyond what a single owner needs or can spend, so this entire segment had no product it could buy and the company had no direct line to it. The recurring product that could reach it did not exist, and the gap itself had not been named as the thing to build. Naming it was where this began.

Executive Summary
Project revenue could not compound, and the growth the owners wanted lived in a segment the enterprise model could not reach. The answer was a new business model, not another project.
The research

Strategy from the field.

A market the company had never served could not be designed for on assumption. So I went to the people the product would serve, rather than reason about them from the enterprise clients we knew.

What watching, not asking, revealed.

Through the lockdown I spent weekends in the places the product would serve: jewellery shops, medical and liquor stores, schools, housing societies, roadside stalls. Sales knew the organisational buyers, but no one had spoken to the end users the product was being designed for, so I went and watched what they did rather than note what they said. The watching mattered. One vadapav stall owner had put up cameras for a reason no market report would surface, to avoid the hours of police questioning that followed any incident at the junction outside. That use case lived only in the field.

What I saw reset the product. Owners used cameras forensically, to review footage after an incident, not to watch live; they were running a business, not sitting at a monitor, and none could staff a person to watch feeds. So the system watches for them: analytics raise an alert the moment something starts, motion, line-crossing, forced entry while armed, and the owner acts in time, a siren to scare off an intruder, a call to the fire brigade or police. Whatever falls outside the analytics, the cloud backup holds, even if the device itself is broken or stolen. Together that is what the product really sold, peace of mind, the restoration of sleep, and it became the promise the product was built around. The same insight later fed into SecureMyShop, the 2024 retail offering built on MonitoringHub, where the pricing carried it: ₹85 a day sits beside chai and transport, costs already accepted, while ₹2,500 a month gets weighed against rent. Same money, a different decision. Pricing is UX.

One finding turned straight into revenue. Owners were quietly afraid of losing footage, so I proposed video backup; it shipped as a paid add-on, short retention free and longer retention charged. A fear in the field became a line on the invoice.

Executive Summary
Weekends in the field overturned the assumptions.

Owners review footage after incidents rather than watch live; the real pain is round-the-clock responsibility. So the product sells peace of mind: the restoration of sleep.

What the field showed

01

Forensic by habit

Owners reached for the cameras after an incident, to review what happened, not to watch live. For this market the product could not honestly be sold as live monitoring.

→ Sell peace of mind, not live surveillance
02

Vigilance fatigue

No one can watch a feed all day; attention decays within minutes. The answer was analytics that watch instead: motion, line-crossing, forced entry, alerting the owner only when something happens.

→ The restoration of sleep as the promise
03

One-time over monthly

Owners were fine juggling several apps. A one-time spend reads as a purchase; a monthly fee reads as a loss felt every month. Mental accounting, not budget, set the resistance.

→ Fed SecureMyShop's low per-camera pricing
04

Behaviour over claims

Many said yes from politeness, not intent, a textbook social-desirability bias. Only observed behaviour and unprompted complaints could be trusted.

→ Trust behaviour, not stated preference
The solution

Mobile proposed. Web shipped.

One product built to carry the whole range, from the owner on a phone to the multi-site organisation in a control room.

From freemium app to web product.

My pitch was mobile-first and freemium: a native app, the first few cameras free, paid tiers above, on the device customers already carried, with unit economics that would have been transformative at scale. The room moved it to web-first, paid from day one, and that was the right call: one web application reached phone browsers and desktops at once, serving SI partners, enterprise clients, and schools alongside the owners on their phones, where a native app would have shut the desktop out at launch. The decision moved faster because the groundwork was already there. My team and I had begun a web version of the company's flagship operator platform, partly prototyped and on the roadmap, and showing it made web-first concrete rather than theoretical. I proposed, argued, listened, and updated, and the result beat either starting position.

What the agency taught me.

Under deadline pressure, an external agency was brought in for the initial screens. Several of us put references forward; the CEO chose. From there the engagement was mine: I briefed them on the whole picture, the features, flows, field findings, and workflows, and reviewed the 72 screens they produced. An agency can produce screens; it cannot absorb an operational domain fast enough to make the real UX calls. So my team built the complete design system from that starting point, including both light and dark themes, the first product in the ecosystem to ship both, and solid enough for the developers to extend without me. When a beta client found the agency's mid-tone blue flat, I did not argue it: I owned the correction and directed my team on prototypes of 5 key pages in a lighter palette, and after internal reviews and iterations we presented them to management and the client. The lighter palette shipped.

One place for everything.

A browser-based, multi-tenant platform with mobile apps on Flutter, pulling cameras, intrusion, access control, fire, and analytics into one place: up to 49 cameras in a single live mosaic that unified any camera brand, configurable dashboards and reports, video backup, and onboarding that paired self-service with a human setup call. The live view flagged offline cameras in place rather than leaving a blank tile, the layout proven in ThinClient and rebuilt for the browser by the team.

Leadership signal
Scheduling is the clearest example of how I move a cross-team call. Engineering wanted a dropdown; I argued operators read time spatially, as blocks of the day, and designed a 48-block grid instead. Rather than win it in a meeting, I built a working prototype and let them react to something real, and it shipped in days. Argue from how the user's mind works, then prove it in something they can use, not in an argument.
Executive Summary
A web-first product that makes one tool carry the whole range. An agency delivered 72 screens; my team built them into the ecosystem's first light-and-dark design system, solid enough for the developers to extend on their own.

Three choices, one product.

01
Web-first over app-first
Mobile-first freemium was the pitch; web-first won, because reaching every user at launch mattered more than the device each was most comfortable on. One web app served phone browsers and desktops at once; a native app would have shut the desktop out.
02
Operations and configuration in one product
TouchControl and TouchConfig were split for enterprise command centres with dedicated admins and operators. MonitoringHub's owner sets up the cameras and checks the alerts next morning, one continuous task, so operations and configuration became one product, with role-based access where a larger organisation still needed the split.
03
Human onboarding as designed product behaviour
Conventional SaaS minimises the post-signup touch. For owners with mixed camera brands, limited IT literacy, and no support, self-service setup would fail at a predictable rate, so the team called every new subscriber to configure their cameras. A short call was cheaper than losing them in week one: onboarding designed in, not a gap.
MonitoringHub alert grid: live camera tiles for an active alert beside a built-in chat workflow for coordinating the response.
The operator's side

An alert opens its cameras, its detail, and a response chat in one place. The operator works the incident and pulls in the right people without leaving the screen. The whole response lives in a single view.

Impact

New business line. New market.

The Dashboard deepened an existing well. MonitoringHub was the river: a new business model, in a new market, sold direct by the company and resold by its SI partners.

The structure carried it.

Before the market could judge the product, I tested it the way I had researched it, by watching. I sat a member of our front-desk team in front of MonitoringHub: no product background, no English, only Marathi and Hindi, working with nothing but the browser's own translation, no manual and no training. He moved through every module and explained the camera and alert pages back to me accurately, asking only a handful of questions.

That tested the work behind the screens, not the screens themselves. If the information architecture, the labels, and the mental model were right, a first-time user in a language the product was never built in could still find his way. He could, which told me the structure was doing the work, not the training, and that it would hold for the owners and operators it was actually for.

What the test proved

A near-zero learning curve, an information architecture that matched how users already think, and labels plain enough to survive machine translation. Accessibility was the structure doing its job, not a feature bolted on. If a design needs a manual, it is not finished.
MonitoringHub's alerts page rendered in Marathi by the browser's built-in translation.
Read in a language it wasn't built in

The screen he used: MonitoringHub rendered in Marathi by the browser alone, a language it was never designed for. He navigated it anyway. Good structure survives translation.

The numbers.

₹7–8 L
Recurring revenue per month, at my departure
A segment the enterprise model never served.
₹11–12 L
Run-rate since, per former colleagues
More than at my exit, not less.
1st
A new business model, in a new market
The company's first cloud SaaS, and its first direct line to this segment.
50+
Operators on SME tenants, approx.
6 to 7 SMEs on one cloud instance, on thousands of devices.

The river, running

Project revenue ends when a project is delivered. A subscription does not.

Every new subscriber and every SI reselling it adds to a base that pays month after month, in a segment the company had never sold to, and it kept earning after I left.

Funding burns. Systems earn.

A startup raised $12.2 million from institutional investors to chase the same end-user security market. It reportedly scaled down by 2024–25.

Intellve never took outside capital. It built its products on its own revenue, several of which I originated or shaped, MonitoringHub among them, and they were still running and earning when I left, and after. That durability was not luck: it came from careful unit economics and the kind of real domain knowledge I spent a decade building into the products. In this market, that outlasted growth-at-all-costs.

A direction, not a blank page.

I built MonitoringHub to outlast me, and documentation ran with the work, not after it: every feature carried its specs, checklists, and handover notes as it was built, and a living architecture map on the internal server kept the system's shape as the team's shared memory rather than my private knowledge. Its last major piece, a component-architecture document from my final 14 months, set a 3-tier model, pages, higher-order components, primitives, and the next phase of the design. It runs today on one maintainer, with a direction to follow rather than a blank page.

What it borrowed, what it spread.

MonitoringHub was a node in the system, not a standalone build. It took ThinClient's lighter-product philosophy and mosaic camera view, the Dashboard's web stack, modular architecture, and design-system approach, and from TouchConfig a filter pattern and the virtualised pagination that let it hold large datasets. In turn it was bundled with the Help Desk system for the integrators running hundreds of cameras who needed maintenance ticketing alongside. Each product made the next one faster to build.

On the record.

Scattered plant surveillance consolidated into one cloud view for centralised quality-control monitoring.

Bisleri International · 16 plants

Cameras across campuses brought under constant health monitoring, with rolling video backup so no incident went unrecorded.

Lighthouse Learning · 5,000+ cameras, 20+ campuses

Cameras and intrusion panels integrated into a single command centre for banking clients.

Checkmate · 650+ cameras, 75+ panels

Strongest product validation

One of the company's largest and most demanding enterprise clients, already paying for the desktop flagship, took up MonitoringHub heavily alongside it by choice. No pitch, no pricing negotiation.

When the buyers hardest to win keep reaching for the lighter product unprompted, the product stands up at the demanding end of the market too. That validation cannot be manufactured.

Before and after.

Before
After
Recurring revenue came only from enterprise clients, through licensing and AMC.
A SaaS subscription opened a new base, small businesses, schools, and societies, compounding with every one added.
Customers were reached only when an SI won a tender, with Intellve as the software partner. No tender, no deal.
Anyone can subscribe directly, from a single camera up, or an SI can resell it as a managed service. Both billed monthly.
Surveillance was sold as hardware, on the promise of catching what happened.
It was sold as an outcome, the restoration of sleep, priced to how owners actually weigh cost.
Operations and configuration were separate products, built for command centres with dedicated staff.
One product carried both, scaling by role and configuration from a single owner to thousands of devices.
Constraints

The limits I worked inside.

What I would do differently, and what the whole effort taught me.

The honest limits.

The freemium tier I let go.

My original pitch was mobile-first and freemium. The collective call reshaped it on 2 counts: web-first over app-first, and paid from day zero over a free tier. The web-first move was the right one and I back it as a decision; letting the free entry tier go is the part I accepted too easily.

The trade-off was the acquisition funnel a free tier builds over time, the low-friction entry that converts to paid later. Paid-only suited a bootstrapped product; the lesson I keep is that "right for now" and "right for growth" are different cases, and the second is worth arguing for explicitly rather than letting it pass.

Self-service setup never finished.

The human onboarding call was right at launch, but it was meant to be a bridge. Device auto-discovery, the self-service camera setup that would have removed the call, was technically complex for browser-based discovery and stayed deprioritised through to my departure.

So onboarding leaned on the call longer than it should have. The lesson is that a deliberate bridge needs its replacement scheduled, or the bridge quietly becomes the permanent design.

The agency chosen on cost.

The implementation agency was selected on cost and convenience, a call that was not mine to make, and the domain-knowledge gap was predictable and confirmed quickly.

An internal hire over the same period might have produced better foundational output. Where I had no authority over the decision, what I could control was insulating the design and the architecture from it, and that is where I put the effort.

Alert management, the most iterated component.

Alert management took 3 structural approaches across 3 years, each transition driven by real operator behaviour at scale, not by a design assumption that held.

The iteration was necessary; the cost was time and change management across an active user base. The lesson I keep is that for the component a whole product turns on, you design for re-architecture from the start, because you will be back inside it.

Three things I carry forward.

You cannot reach product strategy from a desk.

The vigilance fatigue, the dummy-camera deterrence, the police-avoidance use case, none of these came from competitive analysis, market reports, or internal brainstorming. They came from standing in front of actual users and listening, work no one else on the team took on. That asymmetry shaped every meaningful product decision that followed.

A new revenue model needs new thinking at every level.

MonitoringHub was not only a new product; it was a new commercial model for a company that had run project-to-project for over a decade. Subscription demanded different thinking about acquisition, onboarding, churn, infrastructure cost, and pricing psychology, none of them capabilities the company already had, all of them learned in real time, often by getting them wrong first.

What outlasts the funded competitor earns, it does not spend.

Built on bootstrapped resources against competitors with external capital, MonitoringHub is still generating revenue because of careful unit economics, genuine domain knowledge, and pricing built from behavioural understanding. Systems earn. Wells run dry.

How I lead

The work that wasn't design.

Naming a business model and winning it on a picture, and going to the field myself for the truth no report would surface, are not MonitoringHub-only moves. They are how I work, and the leadership page lays out the rest.

Read all principles How I lead