Case Study
IoTailor — Geospatial IoT Operations & Automation Platform
Delivered IoTailor across 5 connected services, implementing a geospatial IoT platform with Ts.ED APIs, Socket.IO realtime delivery, PostgreSQL/Redis/CouchDB data layers, Node-RED automation, and a React operator workspace for live operations and historic playback capabilities.
Role
Full-Stack Developer
Tech Stack
Overview
IoTailor was a multi-service IoT operations platform designed to demonstrate how live tracking, notifications, camera feeds, SOP workflows, and automation could work together in a single product. I worked closely with the CTO across the backend, realtime infrastructure, automation layer, and a large part of the operator-facing application.
The platform was split across 5 packages and had to support 2 operating modes — real time and historic playback — as well as 3 operator views: map, window, and table. My contribution was backend-first, but it spanned the whole delivery cycle: API design, realtime event delivery, historical data access, Node-RED integration, deployment support, and the React workflows needed to make those services usable.
Key Contributions
Backend + Realtime
Worked on the Ts.ED API and realtime layer where PostgreSQL change events were pushed through Socket.IO, with Redis-backed coordination for sessions, subscriptions, and event delivery.
Historical Data + State
Supported time-based APIs and telemetry queries across PostgreSQL and CouchDB so operators could inspect the same assets and events in live mode or at a past time reference.
Automation + SOPs
Worked on notification and procedure flows tied to the Node-RED automation layer. The platform used multiple Node-RED flows, and some of those flows ran 30+ nodes, alongside platform-specific nodes for telemetry, notifications, cameras, and external integrations.
Full-Stack Delivery
Beyond the backend, I implemented a large part of the React operator experience that consumed these services, including map workflows, windowed monitoring, alert handling, and the interaction model for switching between live monitoring and playback.
Engineering Approach
The core challenge was making 5 independent services behave like one operational product through a consistent API and realtime model built on Ts.ED, Socket.IO, PostgreSQL notifications, Redis, and mixed historical data paths across PostgreSQL and CouchDB.
The same asset and alert context had to remain coherent in both live monitoring and historic playback, which required aligned backend contracts, query behavior, event shapes, and UI state rather than separate implementations for each mode.
I focused on keeping that model intact end to end by translating database events into correct user-scoped socket updates, enforcing clean subscription state, and integrating Node-RED automation into the same backend-driven workflow.
Impact
Across 5 services, 2 operating modes, and 3 operator views, I helped deliver a platform that presented a complex operational model as a coherent user experience, not a collection of disconnected features.
What makes it worth showing is that the architecture supported the story the UI told: realtime updates tied to the system of record, historical playback backed by real query logic, and automation integrated into the same backend-driven model.