ProductMonX
MonX
Top-down monitoring for business services: start from the customer's view of service health, then drill into dependencies.
- Role
- Co-Founder
- Period
- Nov 2024 – Present
- Stage
- Functional product
- Type
- B2B monitoring platform
MonX · Service health
Top-down view
Mobile bankingCustomer view
Payments APIDegraded
Core databaseSlow queries
Login serviceHealthy
Card servicesHealthy
NotificationsHealthy
Transactions / min
LiveAnomaly correlated with Core database
Customer impact detected before alerts fired
The problem
Monitoring tools show technical metrics (CPU, database, API latency) but not whether customers are affected. Teams drown in low-level alerts, can't tell which one matters, and often hear about incidents from customers first.
What I did
- 01Identified the gap (technical metrics without the customer's view of service health) and validated it in interviews with IT teams.
- 02Built the MVP end to end (React, .NET, MS SQL), owning architecture, database design and implementation.
- 03Pitched to ~10 prospective enterprise clients with live demos and presented MonX at the Bank Info conference (November 2025) as a monitoring tool for banks and financial institutions.
- 04Positioned it against Grafana, aimed at banks first and insurance next, with an AI module for anomaly detection and metric correlation in development.
Outcome
~10Enterprise pitches
- Positive feedback in live demos with bank IT teams.
- Changed the success metric from closed deals to completed demos to fit long bank sales cycles, and refocused the early-adopter segment.
- Returning to Bank Info in November 2026.
What I learned
Positive demo feedback does not overcome enterprise friction on its own. Long bank sales cycles and attachment to existing tools mean the pitch has to answer "why switch" before "what it does". That is why the metric and the segment changed.
Stack and methods
React.NETMS SQLAI anomaly detection