FAQ
What buyers ask before working with Indeema
Straight answers about what Indeema engineers, how we work with existing products and teams, and what happens from the first conversation to life after launch. Each answer links to the page that covers it in depth.
About Indeema
What we build and where we fit.
Intelligent connected products: devices whose electronics, embedded firmware, connectivity, edge and cloud services, AI and applications have to behave as one system. Examples from our case studies include a connected ventilation unit, a vibration-monitoring system for rotating machinery, a farm-sensor platform with its cloud and apps, and flight electronics for a drone. You can engage us for the whole product or for the layers your team does not cover.
Indeema has 230+ engineers working across electronics, embedded firmware, connectivity, cloud, applications and AI, with 16+ years of connected product engineering since 2010 and 200+ projects delivered. Engineering happens in Lviv, Ukraine and Wrocław, Poland.
The device itself, and the system around it. Indeema designs the electronics, writes the firmware that runs on them, connects the device to edge and cloud services, and builds the mobile and web applications people use. On the drone flight stack the work was the flight-controller and ESC boards; on Prana Platinum it was the electronics, firmware and app of a ventilation unit.
Indeema uses Cognitive IoT to describe connected products and systems that combine sensing, contextual data and intelligence to support or make decisions, act within defined boundaries and improve through measured feedback. It is our working definition and the direction we engineer toward, not a product we sell, an industry standard or a claim that every device needs AI.
Traditional IoT gets data out of physical products and makes remote interaction possible, and that remains valuable. Cognitive IoT builds on it in stages: connected and observable, then intelligent (rules or models turn evidence into recommendations), adaptive (behaviour changes within explicit constraints) and cognitive, where sensing, decisions, action and feedback form one loop. Every stage can be the right destination, and most products in our case studies sit at the connected and observable stages.
Smart home and consumer products, healthcare, energy, manufacturing, oil and gas, agriculture, drones and UAV, and automotive and mobility. Where a product operates changes how it is engineered, so each industry page explains what changes there rather than repeating the same capabilities.
Engineering is done in Lviv, Ukraine and Wrocław, Poland. Indeema Inc. also has a US office in Wilmington, Delaware, and Indeema serves clients across Europe and North America.
Engineering capabilities
Each layer of the product, and the system they form.
Either. Scope is agreed per product, from one layer to the whole system: one board, the firmware, the cloud side, the applications, or all of them engineered together so the interfaces between them are decided once. Each case study states which layers Indeema owned. 8 of the 25 published case studies cover firmware, cloud and applications together.
Yes. Indeema takes responsibility for the electronics inside a connected product: the hardware architecture, component selection, schematics and board layout, the first prototypes and their bring-up, and the bill of materials and files a manufacturer builds from. What bring-up and validation find goes back into the next board revision.
Yes: the runtime architecture (task structure, RTOS choice, memory and power behaviour), board bring-up and drivers, sensor acquisition, radio and protocol stacks such as BLE, Wi-Fi, RS-485 and Modbus, and over-the-air updates with recovery, so a failed update does not leave a unit unusable. We also take over and modernise firmware that already ships.
Yes. On the cloud side: how devices connect and are identified, how their data is received, stored and routed, the APIs that apps and partner systems use, and update delivery. Projects have used AWS, including AWS IoT Core, and Microsoft Azure, including Azure IoT Hub; Indeema is an AWS Partner. On the application side: mobile apps, web portals and dashboards for setup, control, alerts and administration.
Where a decision needs it. In a connected product, AI is rarely a chatbot: it is the logic that turns sensor signals into a state, an alert or a recommendation, and often a rule or signal-processing method is enough. We start from what the product should decide, what evidence it has and where that logic should run, then design the data path, validation and update route around it. Deterministic and safety-related logic stays explicit.
Yes. Inference can run on the product, on nearby gateway compute, in the cloud or in an application, and none is better in general: latency, connectivity, privacy, power and compute decide. Edge AI means running that inference on or near the device instead of sending everything to the cloud. In the Hover Hero proof of concept, lightweight object detection was designed for processing on the drone and tested in a simulated scenario.
We engineer toward bounded autonomy and use the word carefully. A system can leave the decision to a person, recommend, act within rules, or choose and act inside explicit limits with oversight and fallback; autonomy is a design choice, not the finish line. Our autonomous-stage work so far is a concept-stage drone proof of concept with a follow-me mode tested on an existing platform, not a fielded autonomous product.
Working with your product
Existing devices, codebases, equipment and prototypes.
Yes. The work begins by mapping the existing hardware, firmware, cloud and applications before deciding what to keep, change or replace. For VikingSCADA we extended an existing SCADA product with gateway software, cloud monitoring and remote updates; for Dol-Sensors a dedicated Indeema team took over the cloud, web and mobile software while firmware and sensors stayed with the client. 10 of the 25 published case studies started from a product or system that already existed.
Yes, as a layer that sits beside your controllers rather than replacing or programming them. It reads from the equipment through the interfaces it already has, such as an energy meter over RS-485 or SCADA boards through a cellular gateway, and makes condition, status and alerts visible to the people who maintain it. It does not act on the machine. iReDS, for example, turns vibration from rotating machinery into condition-monitoring views.
Yes. Several products we worked on run on hardware we did not design: a third-party battery management system read by a companion app, vendor-built farm sensors whose firmware stayed with the manufacturer, an existing camera, and cellular gateways and industrial PCs in the field. The engineering is the contract between the parts: what each one sends, how it behaves when the link drops and who owns each side of the interface.
Yes, starting with what the prototype proved and what it did not, and what has to change in architecture, hardware, firmware and cloud before it becomes a product you can update and support. On hardware that means revised boards and the files a manufacturer builds from. Product discovery is often the first step.
It depends on what the product already has, because intelligence added later inherits its signals, compute and update path. The first step is an assessment: what the product should decide, whether its data can support that decision, and whether the logic can run on the existing hardware, at a gateway or in the cloud. Sometimes the answer is a rule or a better signal path rather than a model; sometimes a hardware revision has to come first.
Working together
Teams, estimates, ownership and confidentiality.
Three. Engineering ownership: Indeema is accountable for a defined scope, from architecture to evolving what it built, and you decide at agreed gates. Joint product team: Indeema engineers work inside your product team, on your roadmap and against interfaces you both own. Specialist team extension: one scarce specialty joins a team you lead. We agree the model once the scope and the unknowns are clear.
Yes. A common split is a client that keeps hardware and firmware in-house and hands over the cloud and applications; another is a team that owns the platform and needs the embedded layer. Either way the interfaces are made explicit: what the device sends, what the cloud expects, who validates a release and who owns each side.
By separating what is known from what is not. For a new product we usually start with discovery, which turns the brief into clarified requirements, architecture options with trade-offs, a technical risk map and a milestone plan with an estimate you can check. When one unknown carries the risk, such as whether a drone data link reaches its required data rate, it is tested first with a targeted prototype. There is no fixed price list.
Work starts under a signed agreement that covers confidentiality and intellectual property. Access to your code and data is limited to the people on your project and to you.
Each case study describes the starting point, what Indeema owned and what changed. References can be arranged during an evaluation; some projects are under NDA and cannot be named. There are currently 25 published case studies.
Production & lifecycle
Manufacturing files, security, compliance and life after launch.
We prepare the bill of materials, manufacturing files and assembly drawings a contract manufacturer builds from, have prototype boards built through a manufacturing partner, bring them up and feed what we find into the next revision. Factory test and provisioning are one of the interfaces the firmware is designed for. Production volume and the manufacturing route are scoped separately for each project.
As mechanisms decided with the architecture rather than added at the end. Depending on the product, that means device authentication with unique credentials provisioned per device, encrypted communication such as MQTT over TLS, protected Bluetooth pairing, and an update path that can deliver fixes and recover from a failed update. Dependency and security updates continue after launch as part of maintenance.
Certification and regulatory scope are agreed separately for each project. Indeema engineers the product; for regulated products such as medical devices, intended use, clinical meaning and the regulatory route stay with the product owner and qualified advisers. Tell us early which certifications the product needs, because they shape hardware, firmware and documentation from the start.
Update paths and post-launch support are designed in, not added at handover. We can stay on to maintain the device, the cloud and the apps: bug fixes, security and dependency updates, performance work, new features and support for new device and firmware versions. If your team takes over instead, the handover contents are agreed for the engagement. 7 of the 25 published case studies include updating devices in the field.
Getting started
What to bring and what happens next.
You do not need a finished specification. Bring the product goal, what exists today, the hardware and software boundaries you know of, the constraints you are working within and the decision you need to make next. The first conversation is with an engineer.
Indeema fits best when the hard problems sit between disciplines: a device, its firmware, connectivity, cloud and apps that have to work as one product, or an existing product whose layers no longer fit together. Compare your situation with the case studies, which state the starting point and the layers we owned. When the direction is unclear, discovery can come first, and it does not commit you to building with Indeema afterward.
A question about your own product?
Ask an engineer. Bring what exists today and the decision you need to make next; a finished specification is not required.