AetherMesh

The physical layer is deliberately unglamorous: asset tags and beacons attached to equipment, reporting through gateway devices installed around each site. The tags themselves stay cheap and dumb — identity, position signal, and whatever sensor payload the asset class carries — while the gateways do the real work of collecting readings and publishing them into the platform over MQTT. That split is what kept the client free of proprietary hardware lock-in: tags can be swapped or upgraded per asset class without touching the platform, and a new site comes online by installing gateways, not by re-engineering the backend.

At deployment scale that means over 1,000 tagged assets across more than five sites, every one of them visible on a live dashboard with sub-second latency from signal to screen. The operational question AetherMesh answers is the oldest one in facilities management — where is the thing, and is it okay? — but answered continuously, for every asset at once, across every site in the tenant.

Device traffic flows through a fully meshed gateway network into an MQTT broker, and from there into a reactive Java / Spring Boot backend. Reactive matters here: telemetry from a thousand-plus assets arrives as a continuous, bursty stream, and a thread-per-request architecture would spend most of its life blocked. The reactive pipeline ingests, validates, and persists readings through Hibernate while pushing live updates out to the React dashboard — which is how the platform holds its sub-second end-to-end latency without heroic infrastructure.

Multi-tenancy was designed in from the first schema, not retrofitted: every tenant's assets, sites, users, and telemetry live behind strict isolation, because the platform was always intended to serve multiple client organizations from one deployment. The practical test of a multi-tenant IoT platform is boring on purpose — one tenant's misbehaving gateway or telemetry burst must be invisible to every other tenant — and passing that test shaped the ingestion, persistence, and query layers more than any dashboard feature did.

Enterprise asset data is only useful if it reaches the systems where decisions happen — maintenance planning, ERP, site operations tooling. Instead of building each of those integrations bespoke, AetherMesh ships a published REST API and SDK, turning integration from a services engagement into a documented developer task. The two-to-three third-party middleware teams that have built on it completed their integrations in days instead of the weeks a custom integration would have taken — the ~70% onboarding reduction in the numbers above — and did it largely without me in the loop, which is the real test of an SDK.

That choice also changed what the platform is: a system with a published integration surface isn't an internal tool, it's infrastructure other teams can plan around. For a multi-tenant SaaS, that's the difference between selling seats on a dashboard and selling a capability the client's whole software estate can consume.