A commercial platform sets the limits
Its features and supported hardware are fixed by the vendor. Custom needs become change requests on someone else’s roadmap, and the system’s future follows that roadmap rather than yours.
Customer use cases
Two systems that would not fit a fixed platform.
One is an industrial customer building new production facilities for a living process. The other is Manna Insect’s own containerised production unit. Both started from the same choice: a commercial platform with fixed features and hardware, or a complete in-house IoT project. Both were built on MIND AIoT — with the features they needed and off-the-shelf hardware.
On this page
The choice both projects started with
Fit the platform.
Or build one.
Building the whole IoT layer in-house
Sensors, connectivity, edge control, cloud services, dashboards, alarms and updates. For a team whose job is the process, that is a large software project with no end date — and expensive R&D time.
Or a platform built for this
MIND AIoT is a reusable software platform with agentic workflows. Agents integrate the hardware, develop and test each change, and you accept it before production. Hardware stays your choice, and features and changes stay inside the licence.
Both cases below took the third option. Explore the platform
Customer case — anonymised
A production facility built around a living process.
The situation
The customer was planning new facilities for a living production process — animals reared in controlled conditions. What the process needed went beyond standard building automation: climate, ventilation, lighting and feed preparation follow a biological cycle, and much of the required logic was not available as a product, or was priced far beyond the purpose.
The constraint
The team’s expertise was in the process and the biology, not in building an IoT platform. With limited time and people, the realistic options were a commercial platform with its own feature set and hardware — with custom development bought as an outside service — or building the entire IoT layer themselves.
The build
Working with Manna, the facility was developed iteratively on MIND AIoT. Raspberry Pi-based edge nodes read the facility’s sensors and switch its own equipment: central air handling, room heating and humidification, separate ventilation branches, lighting and linear actuators. Deterministic control runs locally on the node and keeps the process running when the cloud connection is unavailable; configuration, telemetry, alarms and history live in the cloud. Operators use a local dashboard on site and the same system remotely. Facility-specific logic — room-by-room climate and airflow control, staged humidification, schedules, failsafes and configurable alarms — was developed for this process, and a dedicated operator workflow was built on the platform’s shared services instead of as a separate customer backend.
The outcome
The facility reached an operating, industrial configuration through staged development rather than one large project. The custom work stayed reusable: the control logic, integrations, telemetry, alarms and operator workflows became platform capability that can be licensed across further deployments rather than being locked to one site. The collaboration has since grown into a follow-on programme.
Manna Insect product case
A containerised production product, not a one-off project.
The need
Manna Insect needed a complete, mobile unit for black soldier fly rearing and breeding: a controlled environment that could be built, shipped and commissioned wherever it was needed — and then repeated as a product.
The constraint
The climate equipment inside the unit is ordinary and globally available. Turning that equipment into a product — automated control, continuous monitoring, remote support — would otherwise have meant a new IoT development project, or a design frozen to one commercial platform’s features and hardware.
The build
The unit runs on MIND. The platform controls heating, cooling, humidification and dehumidification, intake, exhaust and circulation fans and lighting; it monitors temperature, humidity and CO₂; it raises alarms and reports every unit to the same dashboard, with a local dashboard for commissioning and troubleshooting. A documented bill of materials lets local teams source and assemble the hardware from standard components. Growth and change stay software work: a unit can be reconfigured for rearing, breeding, nursing or the full cycle without rebuilding its automation.
The outcome
The container product moved from idea to units operating internationally, monitored and supported remotely by a small team rather than an engineer per site. The platform that carried a custom facility also turned the container into a repeatable product line.
What the cases share
Different systems,
same freedom.
The same starting choice
A fixed commercial platform with its own features and hardware, or a full in-house IoT project — neither fitted a process that needed its own features from the start.
Off-the-shelf hardware
Both systems run on widely available components the customer or a local team can source, not proprietary parts tied to a platform vendor.
Custom features without a custom platform project
Process-specific logic, monitoring and operator workflows were built, tested and accepted on one platform — not from scratch, and not only if a vendor agreed.
Software that stays reusable
Control logic, integrations, telemetry, alarms and workflows became platform capability, licensed per deployment rather than rebuilt for every project.
That is the same platform you can start with today. See what is current and what is developing
Start with your system
Your system doesn’t have to fit someone else’s platform.
Tell us what you build or operate, the hardware you have or plan to use, and the one capability you are missing. We’ll start from a bounded first scope — one component or feature, tested on one node before production.
Tell us about your system