Kelip.io
Kelip.io was an end-to-end IoT development platform — built around a vision where developers could assemble virtual components, simulate their entire IoT project in software, upload firmware directly to physical devices, and visualize live data through a custom dashboard — all in one place. The vision was real. The product never shipped.
IoT development is fragmented by default. Developers work across disconnected tools: hardware prototyping kits, separate simulation environments, manual firmware flashing, and standalone dashboards stitched together with glue code. Kelip.io was designed to collapse all of that into one platform — the full workflow from virtual component assembly to live data visualization in a single environment.
When we tested the market, the signal was clear: the demand wasn't for a general-purpose IoT platform. It was for custom IoT project work — companies with specific problems that needed solutions built for their exact context, not a horizontal tool. We pivoted to custom IoT projects. Kelip.io didn't go to market.
What We Built
Component Assembly
Users build their IoT project virtually — selecting and wiring components (sensors, actuators, microcontrollers) in a visual interface before touching any physical hardware.
Simulation
The assembled project runs as a simulation — device behavior, sensor readings, data flow — testable entirely in software. No hardware required to validate logic.
Firmware Upload
When ready, users push firmware directly from the platform to their physical device — bridging the simulation environment to real hardware without leaving the tool.
Custom Dashboard
Live and historical data from devices surfaces in a custom dashboard built inside Kelip.io — so teams can monitor, visualize, and analyze their IoT data without building a separate frontend.
Tech Stack
EMQX was the core of the IoT layer — the bridge between the platform and real physical devices. When a device publishes data over MQTT, EMQX receives it and routes it into the platform pipeline, where RabbitMQ handles the async processing before data surfaces on the dashboard. The same path runs in reverse for firmware pushes and device commands.
What I Got Wrong
I led a team of 8 people on this product — and I led them the way I knew how at the time: as an engineer. The vision made sense to me. The features followed logically from the vision. So we built them.
What I didn't do was deeply validate who specifically needed this, in what context, and whether the all-in-one platform framing matched how they actually worked. The roadmap was driven by what seemed technically coherent — not by what real users were asking for or actively struggling with.
Eight people, months of work, and a product that worked — but hadn't been confirmed that anyone was waiting for it. That's an expensive way to learn. But it stuck.
Outcome & Impact
A 10x engineer isn't someone who writes more code. They're someone whose product thinking multiplies their technical output.
The vision for Kelip.io was genuinely interesting. The problem it addressed was real. But a real problem poorly validated is still a product no one buys. I was building what I thought users needed. The market disagreed. That gap — between what engineers think users want and what users actually need — is where most products fail. Kelip.io is why every product decision I make at Jenjang starts from the user — not the solution. It's the failure that made me a better product thinker, and a better CTO.