How a Christmas side project became Miradoris

It started during Christmas 2025. I had some time off, and I wanted to build something just for fun. No grand plan, no business model, no pitch deck. Just code and curiosity.

I had been thinking about a problem for a while: how do you visualize a physical environment with all its moving parts? Not just a static floor plan, but a live, interactive map where you can see every asset, every person, every device, all updating in real time. I had worked with enough industrial systems to know that this kind of view simply did not exist for most operations. People were running complex physical environments with spreadsheets and disconnected dashboards.

So I built a proof of concept. An interactive map with assets moving across it, connection lines between them, a sidebar showing properties and status. You could click on a tractor and see its heading, fuel level, current task. You could see drones patrolling overhead, sensor readings coming in from the field.

It was a prototype. Fake data, hardcoded positions, nothing production-grade. But it worked. And it looked good. More importantly, it felt right. For the first time, I could look at a screen and understand what was actually happening in a physical space. Not through tables and charts, but through spatial context.

The idea that would not leave

I went back to work in January, but the project kept pulling at me. I would be in meetings about operational challenges and think: "This is exactly the kind of thing that map interface could solve." Asset tracking across a facility. Task dispatch for field teams. Monitoring autonomous systems from multiple vendors. The use cases kept stacking up.

The more I thought about it, the more I realized the interactive map was just the tip of the iceberg. The real problem was deeper. Companies deploying robots, drones, and smart devices were buying hardware from five or six different vendors. Each vendor had its own control software, its own data format, its own API. There was no common language.

If you wanted to create a workflow like "when the drone detects an anomaly, pause the nearest robot and notify the supervisor," you had to stitch together three different systems manually. That is not scalable. That is not how serious operations should work.

Building the foundation

I started building what would become Miradoris. Not the pretty map this time, but the boring stuff underneath. The data model. The ontology that could represent any physical asset, any location, any task, any rule in a unified schema. The data mapping layer that could ingest telemetry from any vendor and normalize it automatically.

This is the part that most people skip because it is not flashy. But I had seen enough enterprise software to know: without a solid data foundation, everything you build on top is fragile. You cannot orchestrate what you cannot model. You cannot automate what you cannot define.

So I built the ontology first. Then the data mapping engine. Then the workflow system. Each piece designed to work together, each piece built on the assumption that the physical world is multi-vendor by default.

Where it stands now

Today, a working prototype of the real-time operational interface is ready. The interactive map is still there, now designed for real data models instead of hardcoded positions. The core platform layers, the spatial ontology, data mapper, and workflow engine, are being rebuilt from the ground up with a focus on robustness and security. The goal is a production-grade system, not a demo.

It is early. Really early. But the architecture is sound, the vision is clear, and the problem is real. I talk to people in energy, agriculture, logistics, and industrial operations, and they all describe the same pain: too many tools, too many dashboards, no unified picture.

Miradoris is my attempt to fix that. One platform, one data model, one operational view. Hardware-agnostic. Vendor-neutral. Built for the messy, multi-vendor reality of physical operations.

If that resonates with you, whether you are running a facility, building autonomous systems, or investing in infrastructure software, I would love to talk. This is just the beginning.