Show HN: Fostrom, an IoT Cloud Platform built for developers
fostrom.ioHey HN! Arjun and Sid here.
Fostrom is an IoT Cloud Platform designed for developers to make it really easy to get started and scale fleets. We have Device SDKs (in Python, JS, Elixir, more coming soon), Typed Schemas, Per-Device Mailboxes, Programmable Actions, 4 Global Regions for lower-latency connections, and much more.
We've built Fostrom to solve a real need we faced in our previous startup, building a fully automated indoor vertical farm. We spent more time figuring out IoT infrastructure than writing automation logic. Fostrom is the platform we wished existed back then.
Over the last few years we've experimented with a lot of interesting tech and architectures, and settled on an architecture that we believe is quite elegant. We wrote a Go<->Elixir bridge to execute JS code in WASM for Actions, implemented a DuckDB library for Elixir, and wrote a Device Agent in Rust that our SDKs run in the background (https://github.com/fostrom/devicekit).
The most interesting realization we had was about the data architecture. For years, we tried using distributed databases and built complex layers on top of them, but all approaches had significant limitations specifically around consistency and querying. We want to provide operational correctness, rich insights, and reliability. Finally, we came to the conclusion that to achieve this we really need a SQL database for fleet data. So we built a DuckDB-based replicated multi-tenant data layer. We're still improving it (hence the Technical Preview badge) but we're quite proud of this decision. It simplifies the rest of the codebase, while keeping operational complexity in just a few places.
Our vision is to make a powerful IoT platform that enables you to build correct, secure, and reliable connected systems without dealing with any of the plumbing or infrastructure.
Next up, we're gonna launch our CLI, add automatic device monitoring to our Device SDKs, and improve the debugging experience. We have some pretty cool ideas to make Fostrom and the experience of developing connected systems better. We're also going to write more about our architecture and journey soon.
We also published our launch blog post which goes into more detail about our vision, what we've built, and our future plans: https://fostrom.io/blog/introducing-fostrom
Would love for you to try out Fostrom and give us your feedback and thoughts. I've never attempted to use IoT devices for development, but my recommendation is to make the copy quickly explain what problem you are solving. E.g. "Stop spending months building infrastructure to manage your IoT device systems, instead integrate in days" Perhaps with a concrete example with and without your product. Hey, thanks for the feedback. Great point! We're gonna add something like this to the landing page soon. And we're going to write a few blog posts showing quick integrations across different hardware and protocols as well. I've been staring at the same space for a while from the point of view of needing to integrate our user facing application with various hardware platforms provided by partner companies specializing in mostly RTLS solutions. Because these companies are almost universally not very good at software (bad UI/UX, weird bespoke SDKs, lots of proprietary components, etc.), there's a lot of wheel reinvention, integration issues, etc. And the worst is that non of this stuff delivers any value until you build typically very bespoke services on top of this stuff. The software they ship is effectively low level middleware: a necessary evil that the end user doesn't care about. In my view, what's lacking here is good Open Source components and standardized protocols. And out of the box software experiences that deliver true value using those. Companies seem to be defaulting to building walled gardens and low level SDKs. And they just aren't very good at it. It's a mess of low quality, low level software, and a lot of messy integration projects. You can't order any of this stuff on Amazon and expect it to be plug and play. Ironically, the home automation market is much more mature than the industry is at this point. You even have some interoperability for devices, protocols, etc. and some pretty decent open integration platforms, slick mobile applications, etc.. That does not exist for large scale industrial/business usage outside a few narrow verticals/niches (e.g. fire alarms, agv tracking in automotive, etc.). Consumers are much more critical and less forgiving than companies when it comes to buying stuff. If it doesn't work, they'll return it. Something like Apple Airtag is science fiction for asset tracking in an industrial context. It simply does not exist in a usable form. A polished easy to use end user experience that works out of the box. It's easier to track your luggage than it is to track expensive machinery across a supply chain. The widespread software incompetence is holding back the IOT industry as a whole. They all talk big about topics like ESG, energy savings, smart buildings, fancy tracking, etc. But when you pick it apart it's a bunch of chips in a fugly 3d printed housing with some MQTT and Grafana on the side. They throw it over the fence with some proprietary SDK. And good luck building anything that does anything useful. You are typically looking at expensive integrations and consulting projects. Just to connect some hardware thingies to some ERP thingies. We're trying to fix this in our company; just so we can remove the friction of getting companies started with our software solutions. It's hard poking through all the BS in this industry. The core issue is the user/developer experience of Industrial IoT is nowhere near where it should be. I understand where you're coming from, and I feel the same way too. Building a great developer experience is something we deeply care about. Exactly for that reason, we started building our own Device SDKs. We also have support for open protocols such as MQTT and HTTP+SSE, but the Device SDKs enable us to provide a richer set of capabilities. Our SDKs actually speak a custom protocol we developed for higher efficiency. We're also going to add many more features such as automatic telemetry collection and tracing support, which is more feasible with a plug-and-play SDK. Another big issue you pointed out is with documentation, a key part of Developer Experience is always great docs. A compelling model might be standalone open source tooling that works independently, with an integrated platform that ties it all together, creating a strong ecosystem. I've been using Home Assistant with a bunch of Zigbee and Wifi devices at home, and it's been pretty stable. However, for an industrial context, there are already many other hurdles, having a platform handle a lot of the cloud infra and connectivity & monitoring is really helpful.