DEV Community: Mohammed Junaid

From Physical-World Problems to AIoT Ventures: A Practical Framework

Mohammed Junaid — Thu, 08 Oct 2026 10:18:20 +0000

AIoT systems are those which combine connected devices, operation data, software systems and AI to aid decision-making in environments where physical assets and processes are key

This combination is an opportunity for venture building, but not without additional constraints over and above those found in software products.

A good place to start is working backwards from the operational problem.

Define The Physical-World Problem

A good AIoT system starts with a clearly defined operational challenge.

Aim to avoid statements that begin "We should use AI to..." and think first about what is already happening and what information is difficult to obtain:

Which assets or processes are involved?;

What information is currently challenging to get hold of?;

Which decisions are being made based on this information?;

Where are delays or gaps in visibility occurring?;

This defines an actual problem to solve, and not just a technical architecture.

Map The Data Sources

With the problem defined, it's necessary to think about what data can help describe the relevant part of a physical process.

Depending on the environment, this is likely to involve connected equipment, sensors, existing operational systems or data sources - the key point is that it's not about volume, but relevance and reliability

A good AIoT architecture will define how the data from the environment can flow into systems for analysis, and will involve building an appropriate chain of custody:

Physical assets -> Data collection -> Connectivity -> Processing -> AI/analytics -> Operational decision

Each part of this chain must be relevant to the use-case.

Think About Integration Early On

Industrial environments are rarely standalone technology silos

New capabilities are likely to need to work in tandem with existing processes and systems, and must be viewed through the lens of early integration and adoption.

A technically sophisticated solution is of little use if it cannot be made to work within an existing environment.

Bind AI To A Decision

AI models should always have a clear purpose within a workflow, rather than being viewed as an end in themselves.

Ask what decision or action the model's insights are intended to inform, and build an appropriate chain between:

The data -> analysis -> insights -> decision -> action

The closer this is to the original operational challenge, the more likely it is that value will be delivered.

Test If The Problem Is Repeatable

A single successful implementation is rarely enough for sustainable venture building - the most interesting opportunities will always be for organisations with similar underlying problems to solve

This raises the challenge of identifying which parts of the solution are portable, and which require reworking for each environment.

This distinction will define whether a single customer win is interesting, or whether there's potential for a more substantial product-led opportunity.

Look Beyond The Tech Stack

A successful AIoT product always involves more than the model itself, and requires attention to the environment, integration requirements, user processes and the business problem being addressed.

This is why problem-first development can be so powerful - it binds together the technical solution and the opportunities for delivery in the real-world.

A venture-building approach to AIoT can be viewed as a progression through:

Industrial problem -> Data requirements -> System architecture -> AI/analytics -> Operational workflow -> Repeatable product

The actual architecture will vary according to the environment, but the principle of "problem-led tech" should always apply.

Conclusion

AIoT represents an opportunity to bring software intelligence to bear on physical-world operations, but there are additional challenges for building sustainable systems and products that must be navigated.

This makes for a fundamentally different challenge to pure software product development, and a problem-first approach will always be more valuable to venture builders.

Aperture Venture Studio focuses on venture building at the intersection of AI, IoT and industrial environments . Aperture Venture Studio provides a relevant example of this approach.

The most interesting opportunities in AIoT will always be where recurring physical-world problems can be addressed with new data and intelligent software.

Building a Connected Inventory Stack: From Identification to Visibility

Mohammed Junaid — Thu, 08 Oct 2026 09:31:34 +0000

Inventory management is one of these things that many people think “it must be software”, but the physical inventory is physically something that exists outside of software.

Products flow across the different warehouses, materials go to production, there is receiving, picking, transfers, shipping and returns. How do all this things get integrated back to these databases?

An inventory-management architecture would require something else than just an inventory database.

That’s where the many tools to track, read or identify products and items, plus RFID, barcode, BLE, IoT, WMS, automation… enter the fray.

Let’s Get It Identified

Your application has to be able to identify one inventory item, SKU, pallet, container or asset from another.

Barcode is old but works reliably and easily enough to deploy.

RFID can avoid using a barcode scanner by embedding tags on the objects.

But how does it works and what is your object?

Well your mileage will vary depending on the actual product type, how much granularity you need and the overall workflow.

Not Just Identifying, But Capturing Events

You identify some objects and items, what’s next?

What I personally want to capture is:

• When

• Where

• What

Events in any inventory-management process are usually:

Event types range from: Receiving, Put-away, Picking, Movement, Transfer, Shipping, return, and consumption.

Sensors or RFID or BLE or even IoT devices, can be integrated at some point to supplement your inventory information, but again, depends on your use-case.

Integration Time: Connecting The Data Layer

Now we have all these new data points captured with events, but what about integrating this new information to the many layers that need it?

Your enterprise systems may range from an inventory-management software, WMS, ERP, POS, supply-chain, manufacturing or anything that requires the flow of this information from a source.

If there’s no integration in place, everyone will likely end up doing their own thing and synchronizing in an ad hoc fashion, and it can quickly become out-of-synch between systems.

But It Always Come Back To Events

As you think about what to do with your data model and software, maybe you can start with event-driven architecture.

Instead of:

SKU-123 = 50 units…

You would have:

Received → Stored → Picked → Transferred → Shipped

Once again I think it’s always good to model what actually happens on the ground.

It can help with analysis and visibility of what went on in an inventory lifecycle.

That’s when you can then see and analyze what’s wrong and who is at the fault.

Inventory systems and databases, especially event-driven ones, provide a good baseline for such analysis.

But What About Automation?

Once everything works fine, you can think of adding automation to enhance inventory processes.

But again, only if everything has been already validated and you just want to speed things up.

Robotics can also be integrated to the warehouse environment, but only if the overall process workflow fits with your use-case.

But it’s also easy to think “I automate everything and it becomes perfect”. No. Don’t automate if your identification processes aren’t foolproof.

So instead of:

Identify → Automate

Do:

Identify → Capture → Integrate →Validate→Automate

But What About Overall Data Quality?

We’ll have a ton of events, but do we have bad or missing data?

Duplicate events, missing events or erroneous entries can populate databases and wreak havoc on inventory records.

You need to factor data validation and validation exceptions in your overall architectural design.

A warehouse system should not take for granted all the data that flows in.

What About Real-Time And Synchronization?

Depending on your overall inventory workflow, some events may require real-time or near-real time processing, while others can tolerate eventual consistency with periodic synchronization.

The overall technical debt and architecture should reflect your real-world inventory needs.

A bigger environment with more complex workflows will require event-driven inventory processes, while smaller environments will likely be more limited in their synchronization and communication methods.

But the question shouldn’t be:

“Can this system provide real-time?”

It should be:

“Can these decisions wait for synchronization?”.

It’s a more relevant question to ask yourself.

8.Where Smart Platforms Come Into Play

A lot of modern inventory-management systems are starting to integrate a wider variety of technologies to provide enhanced and increased inventory-management and visibility.

Inventory Master is an example of a system that takes inventory management softwares, WMS, RFID, BLE, IoT, automation and robotics — and combines them into an inventory-visibility and inventory-management stack. [See Inventory master website here]

Technologies don’t matter as much as the inventory identification and synchronization across all these layers to have a coherent and consistent physical and digital inventory representation.

Conclusion

Inventory management can be more than “just scanning barcodes”.

It requires an inventory application architecture that reflects the complexity of physical inventory management processes.

Identification and RFID (or other form of recognition), sensors to capture events, integration to exchange this information across different systems, and finally, using this data for analysis or automation.

Once all these layers come together, inventory management stop being a set of periodic processes to make records and entries.

This is all the more true as more and more warehouses are starting the move towards using automation, IoT, RFID to track and optimize their processes.

That’s also why building connected systems, for inventory-management or other purposes, is so compelling to many programmers wanting to solve real problems in a wider context.