Choosing a partner for a connected product is not mainly about comparing hourly rates, headcount, or framework lists. If your product spans hardware, embedded software, mobile or web, cloud services, integrations, security, and AI, the real question is simpler: who can own the seams between those layers?

Before you sign, you should understand how a potential partner makes architecture decisions, handles failures across layers, tests on real hardware, plans updates and recovery, designs security, and leaves you with a product your own team can continue to operate.

Why connected products need a different vendor test

A connected product is rarely “just an app.” A device may collect data, an embedded runtime may preprocess it, a mobile app may configure the device, cloud services may synchronize state, external APIs may extend the workflow, and AI may interpret or act on the result.

That creates a different kind of engineering risk. One layer can look healthy while another is already failing. The app can show the right screen while the device state is stale. The backend can be available while an edge device is offline. An AI feature can look convincing in a demo and still be unusable in the field because the input is poor or there is no safe fallback.

Cybersecurity has the same cross-layer problem. NIST’s April 2026 revision of IR 8259 expands its guidance from the device alone to the full IoT product and explicitly covers both pre-market and post-market activities, including maintenance, support, software updates, and end-of-life. For a buyer, the takeaway is practical: you are choosing a team for a product lifecycle, not just for an initial build.

1. Who owns the whole system, not just each component?

Ask the team to draw the product as one system.

Where is the source of truth for state? Which commands can come from the device, app, or cloud? What happens when two layers disagree? Where does AI run? What happens when it is unavailable?

You are not looking for a prettier architecture diagram. You are looking for clear ownership. If the hardware, app, and cloud teams can each explain their own piece but nobody owns the boundaries between them, integration risk will eventually land on your side of the table.

2. What decisions will be made before development starts?

“Discovery” can mean almost anything, so ask what you will actually have at the end of it.

Will the team define product requirements? System boundaries? Data flows? Integration contracts? Technical risks? Delivery assumptions? Team shape? Scope?

At Allmatics, Product Discovery is used to clarify the business problem, technical feasibility, product requirements, and the engineering plan before full development starts. For a connected product, this is where you want expensive assumptions challenged while they are still relatively cheap to change.

3. What happens when connectivity or dependencies fail?

Do not wait for QA to discover the offline experience.

Ask what the device can still do without the cloud. What will the app show when data is stale? Which operations can be queued? How are retries, duplicate events, and conflicts handled? What happens when a third-party API disappears for an hour?

These are product decisions. Our offline-first architecture guide makes the same point from the mobile side: once several systems participate in one workflow, failure and synchronization boundaries need to be designed deliberately.

4. Who owns the contracts between device, app, cloud, and external systems?

Connected products change over time, and those layers do not always change together.

Ask how APIs, event schemas, firmware versions, and configuration models are versioned. Who approves a breaking change? How is compatibility tested when multiple versions are still active in the field?

This matters even more when several vendors are involved. Multi-vendor delivery can work, but someone still needs technical authority over the interfaces. Otherwise every production issue becomes a meeting about whose component is “working as expected.”

5. How early do you test on real hardware and real operating conditions?

A product that depends on physical hardware should not spend most of its development life inside mocks.

Ask when target hardware enters the test cycle. How does the team reproduce weak connectivity, noisy or missing sensor input, power interruptions, latency, storage limits, and version mismatch? Which of those conditions are tested continuously, not just once before launch?

The point is not to build a dramatic test lab. It is to make sure the engineering process resembles the environment in which the product will actually run.

6. How is security designed across the whole product?

“We follow best practices” is not enough detail.

Ask how device identity is established. Who can change configuration? How is data protected in transit and at rest? How are secrets handled? Which interfaces are exposed? How are software updates authenticated and verified?

NIST’s current IoT manufacturer guidance treats cybersecurity as a product-lifecycle responsibility, including customer communication, maintenance, support, and updates. That makes security ownership a useful vendor-selection question before implementation starts, not a final check after the architecture is already fixed.

7. What is the update and recovery strategy?

The first production release is not the end of development.

Firmware, mobile apps, cloud services, configuration, and AI components may all evolve on different schedules. Ask how the partner versions them, stages rollouts, detects a bad deployment, retries safely, and rolls back when needed.

The important part is not whether a team has “OTA updates” on a capability slide. It is whether they can explain what happens when an update only reaches part of the fleet, a dependency changes halfway through rollout, or a new version has to be reversed.

8. What will we actually be able to see in production?

Imagine a customer says, “the device stopped working.”

What can the support or engineering team see without physically taking the device back? Device health? Software version? Configuration? Recent errors? Connectivity state? Related app or backend events?

For connected products, observability is part of the product support model. Without it, simple failures turn into long investigations and engineering teams end up debugging from screenshots, memory, and guesswork

9. What happens when AI is uncertain, unavailable, or wrong?

If AI is part of the product, ask about its operational behavior, not only the model.

What input quality does it need? What happens below an acceptance threshold? Is there a human review path when the consequence warrants it? Can the feature degrade gracefully if the model or an upstream service is unavailable? Can model placement change later without forcing a redesign of the whole product?

That is the same architectural question we cover in our on-device AI guide: the useful decision is not “AI on device or in the cloud?” in the abstract. It is where each part should run, what data it can access, and how the system behaves when conditions change.

10. How do we keep control of the product and its knowledge?

This one is easy to postpone and painful to discover late.

Before signing, clarify who controls repositories, environments, infrastructure definitions, credentials, architecture records, operational runbooks, and documentation. Ask how knowledge transfer works, how your internal engineers can be onboarded, and what happens if the relationship ends.

A good engineering partner should make the product easier for you to own over time, not create a dependency that becomes harder to unwind every year.

What connected-product delivery looks like in practice

ReadU6 is a useful example of why this kind of ownership matters. The public Allmatics case combines web and mobile software, custom embedded hardware, AI/ML, NLP, IoT, and real-time processing in one aviation communication product. The published delivery phases include Product Discovery, prototype development, system integration and testing, and ongoing deployment and optimization.

The point is not the aviation label. It is the coordination required across hardware, software, AI, and the human interface. Those pieces cannot be treated as separate mini-projects if the final product has to behave like one system.

The ReadU6 case should not be read as evidence of FAA, EASA, or other regulatory approval or certification. We are not making that claim.

How to use these 10 questions with a shortlist

Do not send them as another procurement form.

Give each shortlisted partner one realistic product scenario and talk it through together. Pick something uncomfortable: a device loses connectivity during an update, sensor input becomes unreliable, the app and cloud disagree about state, or an AI feature needs a safe fallback.

Then listen to the questions the team asks you.

A team that can own a connected product should want to understand operating conditions, data authority, lifecycle, deployment constraints, support expectations, and business risk before promising an architecture or estimate.

The decision

You do not need a partner with the longest list of technologies on its website. You need a team that can make the boundaries between those technologies boring: clear ownership, explicit contracts, observable behavior, recoverable updates, and decisions that still hold up after the prototype becomes a real product.

If you are evaluating a connected-product build and want another engineering view before committing to scope or a vendor, Allmatics Product Discovery can help pressure-test the architecture, surface cross-layer risks, and turn the product constraints into a practical delivery plan.

The post How to Choose a Product Development Partner? appeared first on Allmatics.

Start with the constraints that are expensive to change later

A mobile stack is easy to debate in abstract terms because every option can produce a polished demo. The differences become visible when the product reaches edge cases: the network disappears, a background task is suspended, a device firmware update changes behavior, an OS permission model changes, or a new system-level AI capability is available only through a native framework.

That is why we recommend mapping the product constraints before selecting the implementation model. The useful question is not “Which framework is best?” It is “Which parts of this product are most likely to create platform-specific engineering work over the product lifecycle?”

The answer usually sits in six areas: hardware and peripheral access; offline and synchronization requirements; OS and AI integrations; performance and UI complexity; security or regulated workflows; and team/lifecycle economics.

1. Hardware access can turn a shared codebase into a native project anyway

If the app mainly consumes HTTP APIs and standard device features, cross-platform development can keep a large share of product logic and UI in one codebase. But connected products often need more: Bluetooth Low Energy, NFC, USB, camera pipelines, audio processing, background services, local networking, custom accessories, or vendor SDKs.

The more critical those capabilities are to the core workflow, the more important it becomes to test the actual native integration path before committing to a framework. A cross-platform layer can still work well, but teams should budget for native modules, platform-specific debugging, and different lifecycle behavior on iOS and Android.

This is not an argument against cross-platform development. It is an argument against counting “one codebase” as if it automatically meant “one implementation.”

2. Offline-first products should choose architecture before UI technology

For field, logistics, aviation, healthcare, and industrial products, connectivity is often a condition rather than a guarantee. In those cases, the mobile architecture must define local data ownership, synchronization, conflict resolution, retry behavior, and what the user can safely do while disconnected.

Those decisions usually matter more than the UI framework. Native and cross-platform stacks can both support offline-first behavior, but the team still needs an explicit local data model and synchronization contract. If that layer is vague, switching frameworks will not solve the underlying product problem.

This is also where mobile architecture connects to the wider system. The app cannot independently invent how conflicts are resolved if the cloud, device, and backend services have different assumptions about data authority.

We covered the full offline architecture separately in Offline-First Is an Architecture Decision.

3. OS-level AI is making platform depth more commercially relevant

In 2026, mobile operating systems are becoming more active participants in app behavior. Apple’s current developer platform exposes the Foundation Models framework as a native Swift API and uses App Intents to connect app content and actions with Apple Intelligence and Siri. Apple also notes that model behavior can change with OS updates, which means teams need to test prompts and AI behavior against new system model versions.

On Android, adaptive behavior continues to expand across phones, tablets, foldables, desktop-style windows, cars, TVs, and XR. Android’s guidance for apps targeting API level 36 emphasizes responsive and adaptive layouts across larger displays rather than fixed phone assumptions.

These changes do not mean every app should become native. They do mean that platform-specific capabilities should be part of architecture discovery. If Siri actions, on-device models, adaptive multi-window behavior, connected displays, or other OS-level features are strategic to the product, the cost of bridging them through a cross-platform abstraction should be tested early.

For a deeper look at how on-device AI affects mobile architecture, see On-Device AI Mobile Apps in 2026.

4. Performance is rarely one number

“Native is faster” and “cross-platform is fast enough” are both too broad to be useful. Performance depends on the workload.

A standard business app may see no meaningful commercial advantage from implementing every screen twice. A product with real-time audio, video, sensor streams, advanced graphics, heavy background work, or latency-sensitive device communication can have a very different profile.

Teams should separate UI rendering performance from system integration performance. A smooth interface does not prove that background execution, Bluetooth reconnection, media processing, or local inference will behave reliably under production conditions.

The architecture review should therefore include representative technical spikes for the highest-risk workflows. Prototype the highest-risk workflow first. If the stack handles it cleanly, the rest of the product becomes a much more informed decision.

5. Security and regulated workflows change the cost of abstraction

Security requirements do not automatically force a native stack, but they increase the importance of understanding every layer between application logic and the operating system.

Authentication, secure storage, certificate handling, device permissions, local databases, update mechanisms, and third-party SDKs all create attack surface. In connected products, the mobile app may also sit between a physical device and cloud services, which makes identity, authorization, and data boundaries system-level concerns rather than mobile-only concerns.

For regulated or safety-sensitive workflows, another factor appears: evidence. Teams may need to explain how a feature behaves, how failures are handled, how changes are tested, and which component owns a decision. A framework that saves implementation time but makes critical behavior harder to inspect or validate can be the wrong trade.

6. Team economics should include the product lifecycle, not just MVP speed

Cross-platform development can reduce duplicated work when product behavior is genuinely shared. Native development can reduce bridging and platform-specific surprises when the app depends deeply on the operating system. Hybrid/web approaches can be efficient for content-heavy or internal workflows where native capabilities are limited.

The financial mistake is to compare only initial development effort.

A better lifecycle model includes: platform-specific modules; dependency upgrades; OS changes; regression testing; app-store release work; performance debugging; accessibility; observability; and the probability that strategic features will require native APIs later.

The cheapest MVP is not necessarily the cheapest product to operate.

A practical decision map

Choose native first when the product depends on deep hardware integration, latency-sensitive media or sensor processing, extensive background execution, platform-first AI capabilities, or highly platform-specific UX.

Choose cross-platform first when most workflows and business logic are shared, native integrations are bounded and testable, release parity matters, and the team benefits materially from one product codebase.

Choose hybrid/web first when the product is primarily content, forms, dashboards, or internal workflows, native capabilities are secondary, and web delivery or reuse has clear business value.

For many connected products, the realistic answer is mixed. Shared product logic may coexist with native device modules. A cross-platform UI may call native services for Bluetooth or audio. A native app may embed web content for low-risk administrative surfaces. Architecture does not need ideological purity.

What our connected-product work changes about this decision

At Allmatics, mobile development is often one layer of a larger product rather than an isolated app project. ReadU6 is a useful example of that systems view: the verified Allmatics case combines web/mobile software with custom embedded hardware, IoT, AI/ML, NLP, and real-time processing.

That matters because the mobile architecture cannot be evaluated independently from the device and AI workflow. When a product crosses hardware, embedded software, mobile interfaces, cloud services, and machine-learning components, the boundaries between those layers determine reliability and maintainability.

The lesson is broader than one case. Before choosing a mobile framework, define what the app must own, what the device must own, what belongs in the cloud, what must work offline, and which platform-specific capabilities are strategically important. Then choose the stack that makes those boundaries easiest to implement, test, and evolve.

The recommendation: choose the architecture by the hardest constraint

If your shortlist is Swift/Kotlin versus React Native, Flutter, or a hybrid approach, do not begin with developer preference or a generic cost comparison.

Begin with the hardest production constraint. Prototype the risky integration. Map offline behavior. Identify platform-specific AI and system APIs you expect to use. Define security and update responsibilities. Estimate lifecycle work, not only MVP effort.

Then choose the implementation model that leaves the fewest critical assumptions unresolved.

If you are planning a mobile or connected product and the architecture choice is still open, Allmatics Product Discovery can help map the device, app, cloud, integration, and AI boundaries before development starts.

The post Native vs Cross-Platform vs Hybrid: Which Mobile Architecture Fits Your Product? appeared first on Allmatics.

A medical student in Nigeria finishes a hospital shift. At home, he straps an iPhone to his forehead and films ordinary household tasks. He folds laundry, makes a bed, washes dishes and cooks. This is not content for social media. It is training data for robots.

That detail sounds almost too neat for a future-of-work story, but it captures where physical AI is right now. Large language models grew up in a world humanity had already digitized: books, code, forums, images, video and documentation. Robots do not have the same advantage. The internet can explain what a chair is or describe how to fold a shirt. It has far less useful data about grip pressure, wrist movement, or the tiny corrections a person makes when fabric slips or a drawer sticks.

So one of the most futuristic industries on earth is doing something surprisingly old-fashioned. Companies are paying people to show machines how humans move through the physical world.

The internet taught AI to talk. The physical world is harder.

This data gap has been obvious in robotics research for years. Google DeepMind’s Open X-Embodiment project brought together data from 22 types of robots across more than 20 research institutions. Together, they created more than a million robot-training episodes across hundreds of skills and tasks. The point was not that one million demonstrations solved robotics. The opposite was true: collecting that much useful physical data required a scale of collaboration that one lab would struggle to reproduce.

That helps explain the rise of a new kind of labour market. Rather than relying only on robot-generated demonstrations, companies are capturing what humans already know how to do.

The human workforce behind robot training

MIT Technology Review reported on Micro1, a Palo Alto company recruiting contributors across more than 50 countries to record real-world activity for robotics training. One participant in Nigeria, a medical student, records tasks at home and earns about $15 an hour. The footage is intentionally mundane: folding clothes, cooking, cleaning, moving objects. That is exactly the point. Tasks that humans perform without thinking are often the ones we still need to teach robots.

This pattern is also appearing inside workplaces. The Guardian documented factory workers in India wearing head-mounted cameras while sewing, handling tools and performing production tasks. According to the report, some factories did not pay workers extra for the footage. The article also described EgoLab, an Indian data company that says Tesla is one of its major clients. Separately, Tesla has hired Data Collection Operators in the United States. Their job is to wear motion-capture suits and VR equipment while performing movements for Optimus training.

The economics vary widely. Some of this work resembles specialist motion capture and pays accordingly. Other jobs look much closer to global gig work. But the most interesting part is not the hourly rate. It is what companies are actually buying.

We are putting a price on muscle memory.

The tiny correction you make when a glass begins to slip is data. You grip cardboard differently from ceramic, and that is data too. So is the instinct to slow down when something feels fragile. Even the angle of your hand changes when a drawer is heavier than expected.

Humans rarely describe these decisions because we barely notice ourselves making them. Robotics is forcing us to notice just how much intelligence was hiding inside “simple” physical work.

Human demonstrations may only be the seed

The obvious objection is that this sounds impossibly expensive. If future humanoid robots need to watch a person perform every task thousands of times, the economics fall apart.

That is not the direction the industry is moving.

A more practical model is to use human demonstrations as seed data, then expand them with simulation and synthetic data. NVIDIA’s Isaac GR00T 1.7, for example, used roughly 32,000 hours of real demonstrations and first-person human data. NVIDIA added about 8,000 hours of simulated demonstrations and rollouts.

Researchers are also testing how little human data a model needs before it can transfer a skill to new robots and environments. In 2026, the HumanEgo paper reported a 92.5% average success rate across four test tasks using 30 minutes of first-person human video per task. That result came from a controlled research setting. It does not mean 30 minutes of video can teach a commercial humanoid any job. But it shows the likely scaling path: humans provide examples, software creates more training experience around them, and the model learns to apply the skill more broadly.

If that loop keeps improving, the bottleneck changes. The question stops being “Can we record enough human demonstrations?” and becomes “How quickly can a model turn limited human demonstrations into reliable physical behaviour?”

That is where the forecasts start to sound surreal.

Ten billion robots, one billion robots, or something much smaller?

Elon Musk has made the most aggressive public predictions. In 2024, he said there could eventually be at least 10 billion humanoid robots by 2040, with unit prices in the $20,000 to $25,000 range. He has also repeatedly described Optimus as potentially becoming one of Tesla’s largest businesses.

That does not mean 10 billion robots is a forecast we should treat as a base case. Other estimates are dramatically lower.

Morgan Stanley sees a path to more than one billion humanoid robots by 2050, with adoption remaining relatively slow through the first half of the 2030s before accelerating. Its analysts expect industrial and commercial settings to account for most of those robots, with far fewer in homes.

Goldman Sachs is more conservative again. Its published outlook estimated that the humanoid robot market could reach $38 billion by 2035, with around 1.4 million humanoid shipments in that year.

These numbers use different methodologies and time horizons, so lining them up as if they were competing answers would be misleading. What matters is the spread. Depending on whose assumptions you accept, humanoids could become one of the largest technology platforms in history, or remain a much narrower industrial category for far longer than the hype suggests.

Reality in 2026 sits somewhere between the demo stage and the mass-market fantasy. Boston Dynamics has not deployed Atlas at scale. Hyundai is targeting manufacturing capacity of 30,000 humanoid robots annually by 2028. That is a serious production ambition, but it is still several orders of magnitude away from a world with billions of humanoids.

The robot apocalypse is probably not arriving all at once.

That does not mean nothing is happening.

BMW gives us a useful picture of what the early phase actually looks like. At its Spartanburg plant, Figure 02 humanoid robots took part in a ten-month production pilot. BMW says the system supported production involving more than 30,000 BMW X3 vehicles, moved more than 90,000 components, accumulated around 1,250 operating hours and walked roughly 1.2 million steps. BMW has since expanded humanoid testing to its Leipzig plant.

That is not a general-purpose robot replacing a person in every context. It is a robot doing useful work inside a structured industrial environment.

And that distinction matters.

Factories are easier than homes. A predictable production cell is easier than a kitchen with pets, children, clutter, wet surfaces, changing objects and endless exceptions. Warehouses, manufacturing lines and repetitive logistics workflows offer clearer constraints, better safety boundaries and more measurable ROI.

Humanoids do not need to become universally competent before they become economically important. They only need to become reliable enough at a meaningful set of tasks.

So what happens to jobs?

This is where the conversation usually jumps too quickly from “robots are improving” to “there will be no work left.”

Current labour forecasts do not support that simple conclusion. The World Economic Forum’s Future of Jobs Report 2025 projected that technological, demographic and economic shifts would create 170 million jobs and displace 92 million by 2030, for a net increase of 78 million roles. The International Labour Organization has also warned against treating AI exposure as equivalent to job elimination; its work on generative AI suggests transformation is more likely than complete replacement for many occupations.

But there is an important caveat: much of the labour debate so far has focused on software AI.

Writing, coding, analysis, customer support, administration and design became obvious targets because generative AI lives on computers. Physical AI changes the equation. It brings automation into jobs that once seemed protected for a simple reason: someone had to act in the physical world. They had to pick something up, move through space, use a tool or react to an unpredictable environment.

That does not automatically lead to mass unemployment. It may lead to a different kind of productivity shock.

A single person working with software agents and physical robots could produce far more than one person does today. Some jobs will disappear or split into smaller tasks. Others may shift toward supervision and handling exceptions. New roles will also appear around deployment, safety, data, coordination, maintenance and system ownership.

The more useful question is not “Will humans still have value?” It is “Which kinds of human value become scarce when doing becomes cheaper?”

The value shifts from doing to deciding

For years, we reassured ourselves that physical work would remain human because machines lacked dexterity. Then, as humanoids improved, the reassurance moved to creativity, empathy and judgment. That may also prove too simplistic.

A more durable advantage may lie in deciding what should be done, knowing when the rules no longer fit, taking responsibility and resolving conflicting goals. Trust and system design may matter more too. Not because machines could never learn these skills, but because every new layer of automation creates new layers of coordination and accountability.

There is also a strange irony here. Before robots reduce the value of some human labour, they may force us to appreciate how sophisticated that labour always was.

A person folding fabric, stocking a shelf or handling a tool is constantly making tiny perception-and-control decisions. Until somebody tried to teach a robot the same task, much of that knowledge was economically invisible.

Now companies are recording, labelling and selling it.

We may be the generation that teaches machines the physical world

At Allmatics, we do not build humanoid robots. That is exactly why the topic is interesting to us without needing to pretend otherwise.

We work in the layers immediately around this shift: AI/ML, embedded systems, IoT, connected devices, cloud infrastructure and software that interacts with the physical world. In projects like ReadU6, AI and NLP sit inside a wider product that also includes custom embedded hardware, IoT, web/mobile software and real-time processing. The product is interesting not because it is “AI-powered,” but because intelligence has to work as part of a physical, connected system.

Humanoid robotics pushes that same systems problem much further.

Once software starts acting in the physical world, model performance becomes only one part of the architecture. Sensors, connectivity and latency matter. So do local versus cloud computing, updates, observability, security, failure modes and ownership of bad decisions.

A chatbot can hallucinate an answer. A physical system can move the wrong object, apply too much force or fail at the wrong moment.

That is why the next wave of AI may be less about putting a model into every product. The harder job is engineering systems people can trust when AI has the ability to act.

Teams building AI-enabled connected products should map these boundaries during Product Discovery before they harden into production constraints.

We may be teaching machines how to become more capable, but for now, we still believe there is real value in working with humans who care.

At Allmatics, that means a highly personal approach, direct communication and a team that gets deeply involved in the products we build.

So, until the robots take over, we’re here — building software with humans, for humans. If you have an idea worth building, let’s talk.

The strangest part of the robot revolution

Maybe the most interesting thing about humanoid robots is not that machines are becoming more human. It is that teaching them is forcing us to notice how much human intelligence sits below language.

For the first wave of AI, we gave machines the products of our minds: text, code, images, documents and conversations. For physical AI, we are beginning to give them the behaviour of our bodies.

We are, in a very literal sense, building a dataset of ourselves.

That does not tell us whether there will be one million humanoids in a decade or ten billion. It does not tell us which jobs will disappear or which new ones will replace them.

But it does make one question difficult to avoid.

What happens when the machines have learned enough from watching us?

The post We’re Teaching Humanoid Robots How to Replace Us appeared first on Allmatics.

Offline-first mobile app architecture is not something you add before release by introducing a cache. It changes where the product keeps authoritative data, how writes are queued, how conflicts are resolved, what users are allowed to do without a connection, and what happens when connectivity returns.

The practical answer is simple: if a critical workflow must continue when the network is slow, intermittent or unavailable, offline behavior belongs in the architecture from the beginning. Android’s current architecture guidance makes the same distinction: an offline-first application should be able to perform all or a critical subset of its core functionality without network access, with local data commonly acting as the source consumed by higher layers of the app.

That matters far beyond consumer mobile apps. Field service, logistics, healthcare, aviation and connected-device products all operate in environments where “online” is not a permanent state.

At Allmatics, we treat offline-first in connected products as a system-boundary problem, not a mobile-only feature. The app may be only one layer between device behavior, local data, cloud services, integrations and AI.

1. Start with the workflow, not the cache

The first question is not “Which local database should we use?” It is “What must the user still be able to accomplish when the network disappears?”

For one product, offline may mean reading previously synchronized records. For another, it may mean creating work orders, capturing measurements, scanning inventory, recording notes or interacting with a nearby device. Those are different architectural requirements.

A useful discovery exercise is to divide actions into three groups:

– must work offline;

– can degrade gracefully;

– genuinely requires a live server connection.

Authentication refresh, live payments, server-side authorization or model inference may remain network-dependent. Capturing a measurement or completing a field checklist may not. The product should make those boundaries explicit instead of failing unpredictably.

This is why offline-first is primarily a product decision. Engineering can implement synchronization only after the business has defined which actions can be accepted locally and what guarantees users expect.

2. Decide where truth lives

In a conventional online-first app, the UI often requests data from an API and treats the server response as authoritative. Offline-first changes that flow.

Android’s official offline-first guidance recommends that higher layers read from local storage, with network synchronization updating that local source. This creates a stable interface for the product even when the connection changes underneath it.

But “local source of truth” does not mean the device owns every business decision. The backend may still remain authoritative for permissions, shared records, billing, inventory allocation or cross-user state. The architectural task is to define ownership clearly.

For every important data object, teams should answer:

Who can create it offline? Can it be edited from multiple devices? Which fields are server-owned? Can it be deleted locally? How stale can a local copy become? What happens when the server rejects a queued change?

Without those rules, synchronization becomes a collection of exceptions added after bugs appear.

3. Writes are harder than reads

Reading cached data offline is relatively straightforward. Writing data offline is where product architecture becomes visible.

If a technician changes an asset status without connectivity, the application needs to persist that action locally and communicate its state to the user. When connectivity returns, the system needs a retry strategy. If the same asset changed on the server in the meantime, the product needs a conflict policy.

Common approaches include last-write-wins, field-level merging, server authority, explicit user resolution, or domain-specific rules. None is universally correct.

A logistics scan event may be append-only and easy to reconcile. Editing the same customer record on two devices is different. Reserving the same finite inventory from two offline devices is harder again.

The key is to choose conflict behavior by domain semantics, not by whichever synchronization library is easiest to adopt.

4. “Connection restored” is not the same as “everything is synchronized”

A network indicator can tell you that a device has connectivity. It cannot tell you that every queued write reached the backend, every remote update arrived locally, or every conflict was resolved.

Good offline products therefore model synchronization as its own state.

Users may need to know that an action is saved locally, waiting to sync, synchronized, rejected, or requires attention. The exact UX depends on the risk of the workflow. A social draft and a clinical workflow should not communicate uncertainty in the same way.

Apple’s SwiftData and Core Data documentation illustrates another important point: synchronization can be handled through platform services such as CloudKit, but teams still need to design compatible data models and understand that background synchronization follows system behavior rather than acting like a synchronous API call.

This is why “we use CloudKit” or “we have a local database” is not an offline strategy by itself.

5. Offline-first mobile app architecture gets harder in connected products

When mobile software is only one layer of a larger product, there may be several independent connectivity boundaries: phone to cloud, device to phone, device to backend, and backend to third-party systems.

A user can have perfect internet connectivity while the nearby hardware is unavailable. A device can continue collecting data while the phone is disconnected. A mobile app can be online while an external API is down.

That is why connected-product architecture needs to answer more than “Does the app work offline?” It needs to define how the whole system behaves when any link in the chain is unavailable.

This is where our engineering perspective at Allmatics comes from: connected products have to be designed as systems, not as separate mobile, embedded, cloud and AI projects. In the ReadU6 aviation case, the delivered system combines web/mobile applications, a custom embedded device, AI/ML, NLP, IoT and real-time processing. That case is useful here not because the public case claims a particular offline implementation, but because it shows why mobile architecture cannot be designed in isolation from the rest of the product.

The same principle applies in HealthTech. Allmatics’ telemedicine case combines mobile and web applications with APIs, AI, server infrastructure and integration into existing healthcare systems. Once multiple systems participate in one workflow, failure and synchronization boundaries become product decisions.

6. Make the decisions during Product Discovery

Offline-first mobile app architecture is cheapest to reason about before the data model, API contracts and user flows harden.

In Allmatics Product Discovery, we map at least six things:

1. Critical offline workflows: what must continue without connectivity.
2. Data ownership: which layer is authoritative for each object and field.
3. Local persistence: what is stored on-device, for how long, and under what security rules.
4. Sync strategy: pull, push, background refresh, queues and retry behavior.
5. Conflict policy: what happens when local and remote state disagree.
6. UX states: how users see pending, synchronized, stale, rejected or conflicting data.

For connected products, add device connectivity and third-party integrations to the same map. The result is not simply a mobile specification. It is a failure-and-recovery model for the product.

7. Test the transitions, not only the offline screen

Offline-first QA should focus on transitions between states, because that is where data loss and false confidence usually appear. A useful test matrix includes going offline before an action, losing connectivity during a write, reconnecting with queued changes, receiving a conflicting server update, retrying after a rejected write, and switching between Wi-Fi and mobile data while synchronization is active.

Local persistence also changes the security model. Data that exists on the device may remain there longer than a temporary API response, so teams need explicit rules for what can be stored, how sensitive records are protected, what is removed at logout, and what happens when a device is lost or shared. Offline capability should not quietly expand the amount of sensitive data retained on-device.

Observability needs the same treatment. A backend dashboard that reports successful API requests cannot tell the whole story when actions may spend hours in a local queue. Product teams need enough telemetry to distinguish an intentional offline state from a failed synchronization path, without logging sensitive payloads unnecessarily.

The practical test is not simply “Can we open the app in airplane mode?” It is whether the product can move safely through offline, pending, reconnecting, synchronized and conflict states without losing user intent or hiding uncertainty. That failure-and-recovery behavior belongs in acceptance criteria before release.

The decision to make before development

If your product is used only with reliable connectivity and every important action requires a live backend response, an online-first architecture may be the right trade-off.

If users must keep working through tunnels, warehouses, hospitals, aircraft environments, remote sites or unstable mobile networks, offline behavior should not be postponed until QA discovers the first broken workflow.

Good offline-first mobile app architecture starts by defining what must survive disconnection, where truth lives, which synchronization states matter, and how conflicts will be handled before implementation. The user may experience this as “the app still works.” The engineering underneath it is an architectural choice.

If your roadmap includes mobile, connected hardware, cloud integrations or AI, Allmatics can map those boundaries in Product Discovery before they become separate engineering problems.

The post Offline-First Mobile App Architecture: A Practical Guide appeared first on Allmatics.

From 12 January 2027, cloud switching gets cheaper in the EU. Leaving may still be the hard part.

Article 29 of the EU Data Act says providers of data processing services may no longer impose switching charges on customers from that date. That removes one commercial barrier. It does not remove provider-specific databases, IAM rules, managed queues, serverless dependencies, undocumented integrations or an infrastructure setup nobody has rebuilt outside the current account.

The useful question for 2027 is not “Can our provider export the data?” It is “Could we run the product somewhere else without turning the exit into a rebuild?”

What the EU Data Act actually changes for cloud switching

The EU Data Act has applied since 12 September 2025. Chapter VI covers switching between data processing services, including cloud and edge services.

The most visible deadline is 12 January 2027. From then, providers may not charge customers switching fees for the switching process. Until that date, reduced switching charges can still apply, but they cannot exceed costs directly linked to the switch.

The regulation also reaches beyond price.

For infrastructure services, providers must take reasonable measures to support functional equivalence after a move to another service of the same type. For other data processing services, Article 30 requires open interfaces to support switching. European Commission guidance also points to export of data in commonly used, machine-readable formats for PaaS and SaaS services.

There is a less comfortable sentence in the regulation that matters just as much: providers may need to explain when switching is highly complex, costly or impossible without significant interference with data, digital assets or service architecture.

That is where engineering begins.

The legal right to leave and the technical ability to leave are two different things. A contract can remove exit fees. It cannot untangle a product whose business logic, data model and operations are deeply coupled to one provider.

The 2026 European standardisation work programme also names workload portability, APIs, identity and access management, switching procedures and test suites among the areas that need common approaches.

What cloud exit readiness means in practice

Cloud exit readiness is the ability to move an application, its data and its operating model to another environment without disproportionate redevelopment, uncontrolled downtime or loss of critical behaviour.

A company can have excellent cloud infrastructure and still be poorly prepared to leave it.

We usually see the real risk in six areas.

1. Data exports cleanly, but the data layer does not

A database dump can be portable while the production data behaviour is not.

The application may depend on provider-specific replication, extensions, managed search, backup policies, event triggers, access controls or recovery tooling. Exporting rows is only one part of the move.

The better test is whether the destination can reproduce the behaviour the product depends on: consistency, indexing, permissions, recovery, audit history, retention and performance under real load.

If the answer is unclear, the data exit plan is incomplete.

2. Managed services have leaked into core business logic

Provider-native services are useful. Avoiding them everywhere usually creates unnecessary work.

The problem starts when dozens of business modules call proprietary queues, serverless runtimes, workflow engines, storage events or native databases directly. At that point, replacing the cloud service means changing the product.

A healthier architecture makes those dependencies explicit. Some can stay because the business value justifies the lock-in. Others should sit behind interfaces the team controls.

That decision is more useful than trying to make every component “cloud agnostic.”

3. Identity is coupled more deeply than expected

Authentication is usually easy to see. Authorization is where migrations get unpleasant.

Years of service accounts, workload identities, secret stores, KMS policies, role mappings and one-off exceptions can create a hidden dependency graph. Another cloud may offer equivalent concepts without identical behaviour.

A serious exit assessment maps machine identities alongside user identities.

One forgotten service account can turn a technically successful migration into a production outage.

4. Infrastructure-as-code reproduces the current cloud, not necessarily another one

Terraform, Pulumi and similar tools are valuable because they make infrastructure reproducible. Reproducible does not automatically mean portable.

If the code describes hundreds of provider-specific resources, it gives you a precise map of the current dependency graph. That is useful. It is still not an exit plan.

For portability, we separate infrastructure into three groups:

• reusable patterns that can move with limited change;
• provider-specific services with a known replacement path;
• components that need redesign because there is no clean equivalent.

That classification tells you where migration effort will actually go.

5. Observability gets treated as an afterthought

Logs, traces, metrics, alerts, dashboards and incident workflows are part of the production system.

A team can move compute and data successfully and still lose the visibility it needs to operate the product safely. During a cloud move, that is the worst possible time to fly blind.

Monitoring rules, trace context, log retention, dashboards and runbooks should be treated as migration assets, not housekeeping.

6. Nobody has tested an exit

This is the simplest signal.

If the team has never rebuilt the environment from automation, restored production-like data, recreated secrets, reconnected dependencies and run critical workflows in a clean environment, portability is still an assumption.

A slide deck called “cloud exit plan” does not prove the product can exit.

A production-like exit test does.

Run a cloud exit test before you need one

A useful cloud exit exercise is narrower than a full migration project. The goal is to find the expensive surprises while there is still time to choose what to fix.

A practical sequence looks like this:

• Map the real dependency graph: databases, storage, queues, APIs, IAM, secrets, jobs, observability, CI/CD, external integrations and manual operational steps.
• Classify provider-specific dependencies. Keep the ones that earn their complexity. Isolate or replace the ones that create risk without enough value.
• Define the data exit path. Document formats, volumes, transfer windows, retention rules, validation steps and how the destination will prove nothing material was lost.
• Recreate the environment from automation. If the second environment needs archaeology, the first one is not portable yet.
• Reconnect integrations. External systems, callbacks, certificates, IP allowlists, message brokers and scheduled jobs often fail after the “main” application has moved.
• Test identity and permissions. Verify machine accounts, secrets, keys, role mappings and operational access.
• Move observability with the workload. Rebuild dashboards, alerts, logs and traces before the cutover test.
• Run a realistic workload and rollback. A migration path should prove both directions: that the product can move and that the team can recover when validation or performance fails.

This gives leaders something more useful than a generic “multi-cloud strategy.” It shows what can move now, what needs selective engineering work, and what should stay provider-native because the trade-off is sensible.

Where Allmatics fits

At Allmatics, we work with established products where the hard part is rarely writing a new service from scratch. The harder work is changing one layer without breaking the business logic around it.

Our Cloud Solutions work covers cloud migration, infrastructure management and hybrid cloud architecture. Across Product Enhancements and Tech Consulting, we also handle legacy code optimisation, third-party integrations, API work and architecture changes around existing systems.

That combination matters for cloud exit readiness because the problem usually crosses several boundaries at once. Infrastructure can be portable while application code is not. Data can export while integrations fail. Containers can move while identity and observability remain tied to one provider.

A useful assessment has to look across all of them.

One Allmatics platform case shows the architecture principle clearly. In a long-running retail SaaS product, the client’s POS systems were staying in place. We built a connector architecture that exposed transaction data to a central platform instead of forcing the source systems to be replaced. The platform used .NET, AngularJS, Google Cloud and Kubernetes and was designed for multi-tenant operation.

That project was not a cloud-exit exercise, and we do not use it as proof that the platform could move providers unchanged. The relevant lesson is more specific: when the boundary between systems is explicit, one layer can evolve without forcing a rewrite of everything around it.

We have used the same approach in other products by introducing separate services around an existing platform and connecting them through APIs. Good exit architecture often starts with the same discipline: fewer hidden dependencies, cleaner boundaries and a smaller blast radius when infrastructure changes.

A 10-question cloud exit readiness check

Before commissioning a migration, ask these ten questions:

1. Can we recreate the production environment from documented automation?
2. Can we export all business-critical data and metadata in a usable format?
3. Which provider-native services are called directly from business logic?
4. Can we reproduce identities, permissions, secrets and key-management behaviour elsewhere?
5. What breaks if the current provider’s database, queue, storage or serverless service disappears?
6. Are APIs and integrations documented well enough to reconnect them?
7. Can our observability stack follow the workload?
8. Have we restored and tested the product in a clean environment?
9. What is the rollback path if data validation, latency or performance fails?
10. Which components need redesign, and which only need a cleaner boundary?

If several answers are “we think so,” you do not have an exit capability yet. You have an assumption.

What an Allmatics cloud exit readiness assessment can deliver

For teams reviewing cloud risk before 2027, we can turn that uncertainty into a concrete engineering map.

A focused assessment can produce:

• an application and infrastructure dependency map;
• an inventory of provider-specific services and lock-in points;
• a data export, transfer and validation plan;
• an IAM, secrets and key-management dependency map;
• a list of integration changes required at the destination;
• target architecture options;
• selective refactoring recommendations;
• business continuity and rollback requirements;
• a realistic view of what can move as-is, what needs isolation and what genuinely needs redesign.

That is a useful starting point whether the business plans to switch providers, build a hybrid setup, reduce concentration risk or simply negotiate from a stronger position.

From January 2027, EU rules remove one category of switching cost. Engineering teams still control the part that usually determines whether an exit is routine or painful.

If you want to know how portable your current application really is, start by testing the exit while you still have the choice.

The post Cloud Exit Readiness Before 2027: EU Data Act & Portability appeared first on Allmatics.

A legacy application with an LLM endpoint is still a legacy application. The model simply reaches the constraints faster.

AI application modernization is now a concrete architecture problem: the model layer can evolve faster than the software underneath it.

That is becoming a practical problem for technology leaders. Microsoft, citing Forrester’s Q1 2026 Cloud and AI Application Modernization Survey, reports that 91% of IT leaders see application modernization as necessary for enabling AI advances in their business. Gartner now tracks AI-Augmented Code Modernization Tools as a dedicated market category, with capabilities spanning code and architecture analysis, dependency mapping, business-rule extraction, migration planning, refactoring, and code transformation.

The direction is clear: AI is moving into the modernization workflow itself. The harder decision remains human. Which parts of the application should stay, which should move, which should change, and which are no longer worth preserving?

For CTOs and product leaders, that choice matters more than the specific coding agent.

Why AI changes the application modernization decision

Modernization used to be framed mainly around cloud migration, infrastructure cost, end-of-life runtimes, and developer productivity. Those drivers still matter. AI adds another one: can your application safely expose the data, actions, and business logic that AI systems need?

AWS is already treating “agentic readiness” as part of continuous modernization. Its 2026 modernization tooling assesses repositories for issues such as obsolete frameworks and dependencies, while also evaluating whether applications are suitable for interaction with AI agents. Google Cloud’s migration guidance similarly separates rehost, replatform, refactor, re-architect, and rebuild because each path changes a different layer of the system.

That distinction is useful. A company can have modern infrastructure and still have an application that is difficult to integrate with AI. Moving a monolith from a private server to a cloud VM may remove hardware constraints, but it does not automatically create clean APIs, observable workflows, controlled permissions, reliable data contracts, or modular business capabilities.

Before choosing a modernization path, we look at five questions:

1. Is the existing business logic still valuable?
2. Can the current system be tested well enough to change it safely?
3. Is the main constraint infrastructure, code quality, architecture, or the product workflow itself?
4. What data and actions will AI need to access?
5. What is the acceptable blast radius if a migration or AI integration fails?

Those answers usually point toward one of four routes.

Choose the modernization path by the constraint

Replatform when the business logic works but operations are the bottleneck

Replatforming changes the environment around an application with relatively limited changes to the code. Microsoft’s Cloud Adoption Framework describes it as moving workload components to managed platform services when the goal is to reduce operational overhead or improve reliability without full redevelopment.

This route makes sense when the application still does its job, but the team is spending too much time maintaining servers, patching runtimes, managing databases, or handling capacity manually.

Typical examples include:

• moving a self-managed database to a managed database service;
• containerizing a stable application;
• replacing manually operated infrastructure with managed cloud services;
• upgrading supported runtimes while preserving core behavior.

For AI projects, replatforming can remove infrastructure friction quickly. It is often enough when the application already has usable APIs, reliable data boundaries, good authentication, and a testable codebase.

The trap is assuming that cloud hosting alone makes an application AI-ready. If the model still needs to call brittle internal functions, scrape inconsistent data, or depend on undocumented side effects, the bottleneck has simply moved.

Refactor when technical debt is slowing every new capability

Refactoring changes the internal structure of the code while preserving the application’s intended behavior.

The 2026 Microsoft modernization guidance recommends refactoring when technical debt is reducing development velocity or when code is poorly aligned with cloud practices. AWS makes the same problem visible from another angle: its codebase-analysis tooling focuses on hidden dependencies, dispersed business logic, and missing documentation because these issues tend to surface late and make modernization riskier.

Refactoring is usually the right direction when:

• releases are slow because every change touches several unrelated modules;
• business rules exist in code but are poorly documented;
• automated tests are weak or absent;
• a few tightly coupled components create most production incidents;
• the application needs new APIs, event flows, or observability before AI can interact with it safely.

AI-assisted modernization tools can help here. They can analyze large repositories, generate documentation, identify dependencies, propose code changes, and automate parts of version or framework upgrades. AWS reported in June 2026 that its Transform service had processed 7 billion lines of code and estimated 2 million customer hours saved.

Useful numbers, but they do not remove the need for engineering judgement. An agent can propose a transformation. Someone still has to decide whether the target architecture fits the product, security model, operating constraints, and future roadmap.

Re-architect when the system boundaries are the problem

Sometimes the code is maintainable, yet the architecture makes new capabilities expensive.

A common example is a large application where customer data, permissions, billing, reporting, and operational workflows share the same deployment boundary and database model. Adding an AI assistant to that environment is not just a model-integration task. The assistant needs controlled access to specific business capabilities, auditable actions, predictable failure handling, and observable execution.

Re-architecting is justified when the existing boundaries block those requirements.

That can involve extracting services from a monolith, introducing an API layer, moving toward event-driven communication, separating read and write models, or creating a dedicated integration layer for AI and external systems.

Microservices only help when the new boundaries match how the business actually needs to change.

Rebuild only when preserving the old system costs more than preserving its behavior

Rebuild is the most expensive and disruptive route, and it is often proposed too early.

Google Cloud’s current migration guidance positions rebuild for cases where the existing application no longer meets requirements, is too costly to migrate through other approaches, or depends on technology that should no longer be carried forward.

We would add one more condition: the team must be able to describe the business behavior that cannot be lost.

This is where many rebuilds get into trouble. Old systems often contain years of exception handling, operational shortcuts, customer-specific rules, and quiet integrations that never made it into formal requirements. Rewriting code without recovering that behavior can produce a cleaner system that is less useful than the old one.

AI can accelerate reverse engineering, but the work still needs traceability. AWS’s 2026 modernization approach explicitly focuses on extracting business rules and linking generated requirements back to source locations and execution paths. That is the right principle even when different tools are used.

What selective modernization looks like in practice

One of our Allmatics projects is a good example of why the answer is often smaller than a rebuild.

A content provider needed to add AI-driven translation, summarization, and content generation to an existing platform. Instead of replacing the core product, we built a separate AI-powered microservice hosted in the cloud and connected it to the existing system through an API.

Discovery took one week. Development and testing took one month, followed by two weeks of fine-tuning and one week for deployment. According to the project results, content creation and translation became three times faster, while operational costs fell by more than three times.

The important architectural decision was the boundary. The existing product continued to do what it already did well. The new AI capability was isolated, testable, and deployable as a separate service.

We have seen the same principle in older systems. In a verified Clutch review, a healthcare client described bringing Allmatics into a web portal that was only about 30% complete. The team continued from the existing codebase rather than discarding it, automated patient enrollment and results workflows, and helped shift the organization from fax-heavy processes toward online enrollment. The client reported faxed orders falling from almost 90% to 20%, with online enrollment reaching 80%.

Different technologies, same lesson: preserve useful behavior, change the layer that is creating the constraint.

A practical modernization sequence before adding AI

For most established applications, we would not begin with “Which AI tool should we use?” We would begin with a short technical and product assessment.

A useful sequence is:

1. Map the application, dependencies, data flows, business-critical rules, and external integrations.
2. Define the AI use case in operational terms: what data it reads, what actions it can trigger, and what happens when it is wrong.
3. Identify the narrowest architectural constraint preventing that use case.
4. Choose the smallest modernization path that removes the constraint: replatform, refactor, re-architect, or rebuild.
5. Add observability, permissions, rollback paths, and evaluation before increasing AI autonomy.
6. Modernize continuously instead of treating the project as a one-time migration.

That last point is becoming more important. Frameworks, dependencies, security requirements, model providers, and AI integration patterns now change too quickly for modernization to remain a once-a-decade program.

The better question is whether the application can keep changing without every new capability becoming a risky project.

Where Allmatics fits

Allmatics works with companies that already have a product, codebase, data, or connected hardware and need to move to the next technical stage without losing the business logic that made the system valuable.

Depending on the constraint, that can mean cloud modernization, API and integration work, refactoring or re-architecting an existing application, building a new service around the current platform, or developing a custom AI/ML component.

If your AI roadmap is moving faster than the application underneath it, start with a modernization map: what to keep, what to change, what to isolate, and what to retire.

That is a much better place to start a build.

The post AI Application Modernization: Refactor, Replatform, Rebuild appeared first on Allmatics.

On 20 July 2026, the European Commission switched the Digital Product Passport Registry on and opened a testing environment for businesses. The timing matters because the DPP has moved from a policy concept to working infrastructure. Retailers, brands, manufacturers, importers, distributors, and marketplaces now have something concrete to design against.

The first mandatory deadline is not tomorrow. Certain categories of large batteries are scheduled to require a Digital Product Passport from 18 February 2027, while other product groups will follow through sector-specific rules. But the architecture work starts earlier, because the DPP depends on product identifiers, structured data, access rules, APIs, versioning, and reliable ownership of information across systems.

For retail teams, that is the practical point. A Digital Product Passport may be reached through a QR code or another data carrier, but the hard part sits behind the scan.

What changed in July 2026

Three steps landed within one week.

On 14 July, the European Commission adopted harmonised standards for Digital Product Passports under the Ecodesign for Sustainable Products Regulation. Six standards are already referenced across areas including unique identifiers, interoperability, data carriers, APIs, data exchange protocols, and data storage.

On 16 July, Commission Implementing Regulation (EU) 2026/1778 set the operational arrangements for the DPP Registry. The regulation covers registration, access management, user verification, storage requirements, and the technical architecture of the Registry.

Then, on 20 July, the Registry and its testing environment went live.

The Registry does not hold the complete detailed passport for every product. The Commission describes it as an indexing layer: it stores unique identifiers, registration data, and high-level metadata, while the detailed product information remains decentralised. Businesses can register through a secure user interface or through an API, which means DPP registration can be connected to existing product and compliance workflows instead of being handled as a separate manual task.

That API option is where retail architecture starts to matter.

A DPP is only as reliable as the systems feeding it

Retail product information rarely lives in one place.

A PIM may own titles, descriptions, images, and commercial attributes. ERP may hold supplier, purchasing, and accounting data. WMS or inventory software knows stock and warehouse movements. PLM may contain material and manufacturing information. E-commerce platforms publish the customer-facing catalogue. Separate compliance files can sit in document repositories, supplier portals, or spreadsheets.

A DPP adds another requirement: the business must know which system owns each required data point and how that information is kept current.

If product composition changes, which system records the new version? If a supplier updates a material declaration, how does that flow into the passport? If the same SKU exists in three commerce systems, which identifier maps to the regulated product? If access rights differ for a consumer, a repairer, a customs authority, and a recycling partner, where are those rules enforced?

Those are data architecture questions.

The Commission’s current DPP model reinforces that direction. The Registry includes machine-readable data models and documented APIs, while the wider passport framework is built around interoperability rather than a single central database.

For retailers, the useful mental model is a product data service with regulatory responsibilities attached to it.

The retail DPP architecture has five practical layers

1. Product identity

Every passport begins with a stable identifier.

The identifier needs to map the physical product, its relevant model or variant, and any additional level required by the applicable product-specific legislation. The data carrier on the product or packaging then resolves to the correct digital information.

That sounds simple until one product is represented differently in ERP, PIM, WMS, a marketplace feed, and a distributor catalogue

Before implementing a DPP, teams should map the identifiers already in use and define which one becomes the common reference across systems. Creating another parallel ID without that mapping only adds another reconciliation problem.

2. Data ownership

Each passport field needs an owner.

Product composition may come from PLM or a supplier. Repair instructions may be maintained by service teams. Compliance documents can come from legal or quality functions. Retail attributes may be enriched in PIM. Availability and commercial data may live elsewhere entirely.

A useful DPP data map should answer four things for every field:

– source system

– accountable owner

– update trigger

– validation rule

Without that map, the passport can be technically valid and still contain stale or contradictory information.

3. A DPP service layer

Most established retailers will not want every operational system talking directly to the EU Registry.

A dedicated integration or service layer can collect the required data, normalize it, apply validation rules, create the passport payload, handle updates, and keep the external registration process separate from the internal systems of record.

This is also where teams can manage schema changes as product-specific requirements evolve. The DPP rollout is progressive, so the data required for batteries, textiles, iron and steel, furniture, or ICT products will not be identical

The architecture should expect variation rather than hard-code one universal passport.

4. Registry integration

The live DPP Registry supports both a user interface and API-based registration.

For a company with a small number of regulated products, manual registration may be acceptable at first. For large catalogues, frequent product updates, or multiple markets, API integration is the more realistic path.

The integration needs more than a single successful POST request. Teams should define retry behaviour, validation failures, registration status, proof of registration, logging, and what happens when an internal product update cannot be accepted externally.

The least glamorous part of the project is usually the most important: exception handling.

5. Access, history, and audit

A DPP serves several audiences.

Consumers may need product, repair, safety, or circularity information. Repairers and recyclers may need operational details. Authorities need compliance access. Some product data may be public, while other data can be restricted by role and applicable legislation.

The system therefore needs access rules, change history, and a defensible audit trail.

When a value changes, the business should be able to answer who changed it, which source supplied it, what version was published, and when the external passport was updated.

That is especially important once DPP data starts feeding marketplaces, after-sales services, repair workflows, and resale ecosystems.

Online retail makes DPP access part of the product page

The European Commission states that, where products are sold at a distance, online marketplaces will need to make applicable Digital Product Passports accessible.

That creates a frontend requirement as well as a compliance requirement.

For in-scope products, the product detail page should be able to resolve the correct passport from the same identifier model used by the physical data carrier. The page should not rely on a manually uploaded PDF or a copied snapshot that can drift from the current passport.

A customer may reach the DPP before purchase from an online product page, after purchase by scanning a code, or later through repair and resale services. Those paths should resolve to the same underlying product identity and current information.

For omnichannel retailers, DPP readiness becomes another test of whether the product catalogue is genuinely shared across channels or only looks shared at the interface level.

What retail teams can do in the next 90 days

A useful starting point is to find out whether the current product data can support a DPP implementation.

Here is a practical readiness sequence.

1. Map exposure by product category. Identify which products you manufacture, import, distribute, or sell that are likely to fall under upcoming DPP requirements. Confirm the relevant role your company plays for each category.

2. Inventory the data. List the information that already exists across ERP, PIM, PLM, WMS, supplier systems, document repositories, and commerce platforms. Mark the gaps and duplicate sources.

3. Assign ownership. Decide which system and team own each important data field. If two systems can overwrite the same value, resolve that before building the passport flow.

4. Map identifiers. Document how SKU, GTIN, internal product IDs, model numbers, supplier IDs, and any regulated identifiers relate to each other.

5. Use the Registry testing environment. The Commission has made a test environment and user guidance available. Run one narrow product flow through it before designing a large integration.

6. Design updates, not only first registration. Products change. Supplier data changes. Documentation gets revised. Build for versioning, validation, and controlled updates from the start.

7. Put DPP access into the commerce journey. For affected products, plan how the passport will appear on product pages, mobile experiences, after-sales flows, and physical data carriers.

This work creates a useful by-product even before a deadline arrives: a cleaner map of product data ownership.

 What our retail delivery work suggests

Allmatics has already seen the cost of fragmented retail data in a different context.

In one retail automation project, product listings had to flow to distributors through XML exports, warehouse teams needed reservation and transfer workflows, courier services were connected through APIs, and payment and notification functions had to work inside the same operating model. The central engineering problem was making several systems agree on the same product and order reality.

DPP projects bring a different regulatory scope, but the integration pattern is familiar.

A strong implementation will usually avoid duplicating product data into a new compliance silo. It can establish clear ownership in the systems that already run the business, then add a controlled layer that validates, transforms, publishes, and audits the passport data.

That is also why product discovery matters here. Before choosing a platform or starting API work, teams need a map of product categories, source systems, identifiers, ownership, access rules, and update events.

Otherwise, a DPP project can become another database that needs to be reconciled with everything else.

The decision to make now

The DPP Registry is live. The testing environment is live. The first mandatory product deadlines begin in 2027, and the framework will expand progressively across more categories.

Retail teams can prepare without rebuilding the entire stack.

The more useful question is whether the stack can identify one product consistently, assemble its passport from trusted data, publish through an API, update safely, and show the right information to the right user without a manual reconciliation step.

If the answer is unclear, that is the work to start now.

At Allmatics, we help retail and e-commerce teams map product data flows, design integration layers, and build the web, mobile, and backend services needed to connect existing systems without forcing a full replatform.

Frequently Asked Questions

Is a Digital Product Passport mandatory for every retail product in 2026?

No. The DPP is being introduced progressively through product-specific EU legislation. Certain batteries are the first group with a mandatory date in February 2027, while other categories follow on separate timelines.

Does the EU Registry store the full Digital Product Passport? 

No. The Commission describes the Registry as an indexing service that stores unique identifiers, registration data, and high-level metadata. Detailed passport information remains decentralised.

Can DPP registration be automated? 

Yes. The live Registry supports registration through a secure user interface and through an API, allowing companies to integrate the process with existing systems.

Do e-commerce and marketplace teams need to care about DPP access?

Yes, when they sell products covered by applicable DPP legislation. The Commission states that for distance selling, online marketplaces will need to make the relevant DPP accessible.

The post Digital Product Passport Retail Readiness: Architecture Guide 2026 appeared first on Allmatics.

A barcode scanner can complete thousands of reads during a shift and still leave the manufacturer with almost no understanding of what happened around those reads.

Which devices were used most heavily? Which barcode types caused repeat attempts? Did one warehouse lose time because of battery degradation, poor connectivity, or an application problem? Which units are approaching maintenance?

Hardware alone rarely answers these questions. It records an action. The software layer gives that action context.

That distinction matters more in 2026 because logistics hardware is moving into connected operating environments. Gartner describes physical AI as the combination of AI models, IoT sensors, robotics, and automation systems that support real-time sensing, analysis, and execution across warehouses, transportation, and manufacturing.

The 2026 MHI Annual Industry Report, developed with Deloitte and based on responses from more than 500 supply chain leaders, found that 56% of organisations expect to increase spending on supply chain innovation. More than half plan to spend over $1 million, while 17% expect to spend more than $10 million. The report’s harder point is that buying technology is not enough. Results depend on how well companies integrate and operationalise it across connected, real-time networks.

For manufacturers of rugged mobile computers, scanners, printers, sensors, telematics units, and warehouse equipment, the product boundary has shifted. Customers still care about scan speed, drop resistance, battery life, ingress protection, and repairability. They also expect visibility, remote control, integration, and evidence that the device improves an operational process.

A stronger casing can extend the life of a device. A software layer can extend the life of the product line.

What the software layer actually includes

For logistics hardware, it usually includes several connected components:

• an application on the device or at the edge;
• secure device identity and configuration;
• telemetry on usage, errors, battery condition, connectivity, and performance;
• APIs or middleware connecting the device to WMS, TMS, ERP, inventory, or customer systems;
• a cloud or on-premise platform for storage, management, and analytics;
• dashboards for operations, support, and product teams;
• update, access-control, audit, and vulnerability-management processes.

Not every product needs all seven. A handheld scanner may begin with an Android application and a web dashboard. A fleet telematics unit may require edge processing, event streaming, and integrations with route-planning and maintenance systems.

The architecture depends on the use case. The business logic is consistent: the device becomes more useful when its data can be interpreted, managed, and connected to the customer’s workflow.

Zebra’s June 2026 warehouse guidance makes the same practical point. Warehouse modernisation works when rugged devices are intentionally connected to intelligent software platforms. With the right software, devices can also gain new workflow capabilities without waiting for a full WMS replacement.

Why a better device eventually reaches a ceiling

1. The manufacturer cannot see how the product is used

A device can be technically reliable while being poorly matched to the real workflow.

Perhaps one model performs well with standard barcodes but causes repeated attempts with damaged labels. Perhaps a unit advertised for a full shift loses capacity after months of cold-storage use. Perhaps customers deploy devices in ways the product team never anticipated.

Without telemetry, product decisions depend on support tickets, periodic customer calls, and isolated field reports. Those inputs tend to capture the loudest problems, not the most frequent patterns.

A software layer can show usage by device, user, site, shift, barcode type, application version, or task. It gives the manufacturer a clearer answer to a basic product question: what is the hardware actually doing after it leaves the warehouse?

2. Support remains reactive

When support has no access to device status, every incident begins with reconstruction.

What model is affected? Which operating-system build is installed? Was the device online? Did the scan engine fail, or did the application reject the data? Is the issue limited to one site?

Remote diagnostics, logs, fleet status, and controlled updates reduce that ambiguity. They also help separate hardware defects from application, network, and workflow problems.

This does not remove the need for field service. It makes field service less blind.

3. The device is disconnected from the operational system

A successful scan has little value if the resulting data is entered into the wrong record, delayed in a queue, or passed to another system without context.

The software layer decides what happens after the beep:

1. Validate the barcode.
2. Associate it with a user, location, order, asset, or shipment.
3. Apply the relevant business rules.
4. Update the operational system.
5. Confirm the action to the employee.
6. Retain an auditable event.

This is where hardware begins to affect inventory accuracy, picking, receiving, traceability, maintenance, and customer service.

The need for that chain is becoming more visible as identification standards evolve. The GS1 2D Barcode Playbook released in 2026 explains that the migration to richer barcodes requires more than compatible scanners. Middleware, ERP, inventory, fulfilment, and analytics systems may all need updates to process batch, serial, expiry, and product-version data.

Reading the code is one task. Making the data operational is another.

4. Product differentiation becomes easy to copy

Hardware specifications converge. Competitors can source similar processors, scan engines, screens, radios, and enclosures. Price and availability then carry more weight.

A software platform creates a harder-to-copy layer around the device:

• historical performance data;
• customer-specific workflows;
• integration templates;
• fleet-management tools;
• analytics;
• administrator roles;
• APIs;
• update and support infrastructure.

These capabilities reduce the amount of work customers must perform around the hardware.

They can also support subscriptions for analytics, fleet management, premium support, benchmarking, or workflow modules. The exact model depends on the market, but recurring value requires recurring utility.

A real example: adding analytics to rugged scanning hardware

Allmatics worked with a UK company that manufactures rugged mobile devices for logistics and warehousing. The client wanted to add a web and mobile system capable of collecting and analysing barcode-scanner usage.

The company had no in-house software development team. Before committing to the product, it needed enough technical clarity to understand whether the idea was feasible, what the system would require, and how quickly an MVP could be delivered.

The project started with a two-week discovery phase. A seven-person team then built the initial software in approximately two and a half months, followed by testing on the client’s devices.

The MVP included:

• an Android application for barcode scanning and data collection;
• a web application for analytics and user management;
• a server environment;
• a Product Requirements Document;
• device-agnostic comparison of scanning performance.

The platform tracked activity by device, user, and day. It could surface scanning frequency, commonly used barcode types, scan timing, device-utilisation patterns, and comparative performance across scanners.

The collected data also created a foundation for maintenance planning, including closer monitoring of operating hours and battery life cycles.

The decisive outcome was the change in the client’s product. The company moved from selling rugged equipment with limited visibility after deployment to offering hardware supported by usage analytics and a customer-facing software experience.

Discovery took two weeks. The MVP was ready in roughly three months.

There are no public figures showing a specific revenue increase or percentage reduction in downtime, so we will not manufacture one. The confirmed result is narrower and still commercially relevant: the software component increased the product’s utility and gave customers operational data they did not previously have.

Read the full Allmatics barcode-scanning analytics case study.

Five capabilities worth designing first

Hardware companies sometimes begin with a long feature list. A stronger starting point is a small set of capabilities connected to actual operational decisions.

Device identity

Every event should be attributable to a known device, model, configuration, software version, location, and, where appropriate, user.

Without reliable identity, fleet analytics quickly becomes questionable.

Event capture

Define the events that matter before collecting everything.

A scan, failed scan, reboot, battery-health change, connectivity loss, configuration update, or unusually long task may each support a different decision.

Integration contracts

Decide how the platform will exchange data with customer systems.

APIs, webhooks, message queues, batch files, and offline synchronisation all have a place. The choice should follow the customer environment, connectivity constraints, and required response time.

Operational dashboards

A dashboard should answer a role-specific question.

A warehouse manager needs different information from a support engineer or product owner. One screen filled with every available metric usually creates more searching, not more clarity.

Lifecycle controls

Connected hardware requires update policies, access control, logs, support periods, and vulnerability handling.

Under the EU Cyber Resilience Act reporting rules, obligations for actively exploited vulnerabilities and severe incidents begin on 11 September 2026. Manufacturers must be able to detect, assess, and report security issues affecting products with digital elements.

A product that cannot be monitored or updated becomes harder to support as its installed base grows.

Build, buy, or integrate?

A hardware company does not need to build every component internally.

Commodity capabilities such as identity providers, infrastructure monitoring, mobile-device management, and cloud storage can often be purchased.

Customer systems such as WMS or ERP should usually be integrated rather than recreated.

The parts worth building are those that encode product knowledge or create differentiated customer value.

For a scanner manufacturer, that may include device-level telemetry, performance benchmarking, scan-quality analysis, and workflows tuned to its equipment.

For a sensor company, it may be edge logic, calibration management, alerting, and domain-specific analytics.

A useful test is simple: would customers notice if this capability were replaced by a generic tool?

When the answer is no, buying may be sensible. When the capability carries your product logic, customer experience, or data advantage, it deserves more control.

Signs that the product has outgrown hardware-only thinking

Common signals include:

• customers ask for a dashboard, API, or remote configuration;
• support cannot diagnose issues without screenshots and serial numbers;
• product teams receive little data from deployed units;
• each enterprise customer requires a separate integration;
• customers compare devices mainly on purchase price;
• firmware and application versions are difficult to track;
• data is available on the device but not usable by operations;
• the company wants recurring revenue but has no recurring product capability.

Several of these together usually point to a product architecture problem.

The device is the beginning of the system

The logistics market still needs reliable hardware. Warehouses are physical environments, and devices must survive drops, dust, cold, long shifts, unstable connectivity, and hurried users.

Yet the value of that hardware increasingly depends on what happens around it.

Gartner’s 2026 supply-chain trends place real-time sensing, analysis, and execution in the same operating model. MHI’s findings point toward connected software and physical systems. Zebra’s warehouse guidance puts rugged devices and intelligent software platforms in the same modernisation plan.

For a logistics hardware manufacturer, the practical question is which decisions the product should help customers make, which workflows it should connect, and which data should remain useful long after the scan.

That is the software layer worth building.

Planning a software layer for an existing logistics device?

Allmatics helps logistics and hardware companies evaluate product ideas, define architecture, and build web, mobile, cloud, and embedded systems around physical products.

A focused discovery should clarify the users, core workflows, integration boundaries, technical risks, MVP scope, and realistic delivery plan before the company commits to full development.

Explore our custom logistics software development experience or contact the Allmatics team to discuss your product.

The post Why Logistics Hardware Needs a Software Layer appeared first on Allmatics.

On July 21, 2026, Microsoft and Mistral announced a multibillion-dollar expansion of their partnership. The agreement adds European GPU capacity, brings more Mistral models into Microsoft Foundry and Copilot Studio, and supports deployments ranging from the public cloud to fully disconnected environments.

For European enterprises, especially those operating in healthcare, manufacturing, finance and public infrastructure, the announcement addresses a real concern: how to use capable AI models without losing control over sensitive data and essential operations.

The Microsoft–Mistral announcement arrives as the European Union continues investing in AI Factories and AI Gigafactories. Europe wants more compute capacity, more regional model development and less dependence on infrastructure controlled elsewhere.

That matters.

But an uncomfortable detail often gets lost in the discussion: a model running in Europe does not automatically give a company control over the product built around it.

The server location answers one question. The software architecture answers the rest.

Can the company replace the model without rebuilding its application? Can it move workloads between the cloud, a private environment and local infrastructure? Does it control the prompts, business rules, retrieval logic and evaluation data? What happens when an external API changes its pricing, limits or terms?

Those decisions sit inside the codebase.

Sovereign AI Architecture Goes Beyond Data Residency

Data residency is usually the first issue discussed in a sovereign AI project. It determines where information is stored and processed, which legal frameworks may apply and whether a workload can leave a particular jurisdiction.

For some systems, that is enough. A low-risk internal writing assistant may work perfectly well through a managed API hosted in an approved region.

The picture changes when AI touches patient records, operational infrastructure, proprietary manufacturing data, financial decisions or customer-facing workflows.

In those cases, control has several layers:

• Data control: where source data, prompts, logs and embeddings are stored.
• Model control: which models can be used, customized, replaced or deployed privately.
• Application control: who owns the workflow, permissions, interfaces and business logic.
• Operational control: whether the system can continue working during a network failure, provider outage or service restriction.
• Commercial control: whether the economics remain viable when usage, token prices or licensing terms change.

A company can satisfy the first layer and remain heavily exposed across the other four.

For example, an AI application may use a European cloud region while depending on a provider-specific agent framework, proprietary vector storage, closed evaluation tools and model-specific prompts spread across the application. Moving the workload later may require a substantial rewrite.

The infrastructure is regional. The dependency is still deep.

Where AI Vendor Lock-In Actually Hides

Most teams do not deliberately create vendor lock-in. It develops gradually.

A proof of concept starts with one API call. The test works. Then the team adds retrieval, document parsing, tools, memory, user permissions and an admin panel. Six months later, the AI provider is woven through the entire product.

The dependency usually appears in four places.

1. Model-specific application logic

Different models handle prompts, tool calls, structured outputs, multimodal inputs and context windows differently.

When model-specific instructions are written directly into backend services, switching providers becomes a software migration rather than a configuration change.

Even a small difference in output structure can affect downstream validation, reporting or user interfaces.

2. Proprietary retrieval infrastructure

Retrieval-augmented generation often involves document ingestion, chunking, embeddings, vector storage, metadata filters and ranking.

If each component is tied to one vendor’s formats and APIs, the company may technically own its documents while losing practical control over the system that makes those documents usable.

This becomes especially painful when a business has already processed millions of records.

3. Workflow logic inside external platforms

Low-code agent platforms are useful for testing ideas. Problems appear when approval rules, exception handling, integrations and operational knowledge remain inside a platform that cannot be reproduced elsewhere.

The model may be replaceable. The workflow is not.

4. Logs and evaluation data

Production AI requires more than application logs.

Teams need to understand which prompt was used, what context was retrieved, which model responded, what tools were called, how much the request cost and whether a human corrected the result.

That history becomes one of the most valuable assets in the system. It helps improve prompts, compare models, investigate errors and prove how a decision was produced.

When this information exists only inside a provider dashboard, the company loses part of its own operational knowledge.

The Software Layer Is the Part a Business Can Own

A model will change. Prices will move. Better providers will appear.

The durable asset is the software layer around the model.

That layer includes the company’s data structures, integrations, access rules, workflow logic, interfaces, review processes and operational history. It contains the parts that reflect how the business actually works.

This distinction has shaped several projects at Allmatics.

In one content-processing project, the client needed to introduce AI into an existing platform without rebuilding the core product. The Allmatics team developed a separate AI microservice hosted in a cloud environment and connected it to the client’s system through an API.

According to the AI-powered content optimization case study, the resulting workflow reduced operational costs by more than threefold and accelerated content production.

The important architectural choice was separation.

The original platform remained responsible for the business process. The AI capability operated through a defined service boundary. Prompts, processing logic and future model changes could be handled inside that service without forcing the client to rebuild the main application.

That pattern is useful far beyond content generation.

A separate AI layer can support:

• several model providers;
• private and cloud-based models;
• model selection based on task or sensitivity;
• centralized access policies;
• prompt versioning;
• caching and cost limits;
• fallback rules;
• unified monitoring.

The provider can change while the business workflow remains stable.

A Model Is Only One Component of an AI Product

Document processing offers a clear example.

An organization may describe its need as “using AI to process documents.” In practice, the model handles only part of the work.

The full system may need to receive files, identify their type, extract text, detect tables, validate required fields, structure the data, flag uncertain results, route exceptions to a human and export the final output into another system.

Allmatics applied this broader product approach while developing DocStreams, an AI-powered resume processing platform.

The platform converts unstructured PDF resumes into standardized, structured documents. Its value depends on the complete workflow: file processing, data extraction, formatting rules, validation and export.

A newer OCR model could improve extraction quality. It would not replace the product.

This is why ownership of the workflow matters. When the application logic belongs to the business, individual AI components can be tested and replaced as the market develops.

When the workflow belongs to a provider, every model decision becomes a platform decision as well.

Regulated Industries Need Control at the Workflow Level

Healthcare systems make the distinction even clearer.

A clinical AI assistant may use a strong medical model, but the model alone cannot manage patient access, consent, clinical roles, audit history, document retention, integrations or human approval.

Those controls belong in the surrounding software.

In an HealthTech project, the team built an AI assistant around Google Med-PaLM 2 for private healthcare providers. The work included the wider medical workspace rather than a standalone chat interface.

The platform had to organize patient information, support clinical workflows and fit into the way healthcare professionals already worked.

Another Allmatics healthcare project shows how much impact the surrounding workflow can have even without generative AI. A medical provider relied heavily on fax-based enrollment and patient-result processes. Allmatics completed and extended its web portal, automated key operations and built custom enrollment forms.

In the client’s verified Clutch review, faxed orders fell from almost 90% to 20%, while online enrollment reached 80%.

The result came from redesigning the process around software. A model alone could not have produced it.

The same principle applies when AI is introduced. The organization needs control over where data moves, who can access it, how results are reviewed and what happens when the model is unavailable or uncertain.

For that reason, sovereign AI architecture becomes particularly relevant in healthcare, aviation, industrial systems, logistics and other environments where continuity and traceability matter.

What a Vendor-Neutral AI Architecture Looks Like

There is no universal architecture for every AI product. A sensible design starts with the workload, the data and the level of risk.

Still, several patterns make future changes less painful.

Keep models behind an internal AI gateway

The application should call a company-controlled service rather than communicate directly with several model providers.

That service can standardize requests and responses, apply access rules, select the appropriate model and record usage.

A customer support request may go to a fast managed model. A sensitive document may be processed by a private model. A low-confidence response may be sent to a second model or a human reviewer.

The application does not need to know every implementation detail.

Store business logic outside prompts

Prompts are useful, but they should not become the only place where process rules exist.

Validation requirements, permissions, approval thresholds and exception handling should remain visible in the application layer. This makes the system easier to test, audit and maintain.

A prompt can instruct a model to return a structured answer. The backend should still verify whether that answer satisfies the required schema and business rules.

Control the data pipeline

Document ingestion, preprocessing, metadata, retention and deletion rules should be designed as first-class parts of the product.

This gives the organization a clear map of where information enters the system, how it is changed and where it is stored.

It also makes future migration more realistic. The company can regenerate embeddings, change a vector database or introduce a new retrieval method without losing the source data and metadata needed to rebuild the index.

Build observability into the product

Production teams need their own operational record.

At minimum, they should be able to trace:

• the user or system that initiated a request;
• the model and version used;
• the prompt or prompt version;
• the retrieved context;
• tool calls and external actions;
• latency and cost;
• validation results;
• human corrections.

This information helps engineering teams compare models and troubleshoot failures. It also gives product owners a more honest view of where AI contributes value and where it creates extra work.

Design for more than one deployment mode

Microsoft and Mistral are explicitly supporting cloud, cloud-connected and fully disconnected deployments. That range reflects how different enterprise workloads have become.

Some tasks require cloud scale. Others require local processing because of latency, confidentiality or service-continuity requirements.

A portable application layer allows an organization to use both.

For example, a system may process sensitive source data locally, send anonymized content to an external model and store the final operational record in the company’s own environment.

The right boundary depends on the process. It should be decided deliberately, before production usage makes the existing design expensive to change.

Sovereign AI Architecture Does Not Mean Running Everything On-Premises

Private infrastructure brings control, but it also brings cost and responsibility.

The organization must provide compute capacity, deployment pipelines, security updates, monitoring, model maintenance and staff capable of operating the environment.

For many ordinary workloads, a managed cloud model remains the practical choice.

A good architecture leaves that choice open.

It allows the company to keep low-risk, high-volume tasks in a managed environment while moving selected workloads to a private cloud, local infrastructure or edge device.

Allmatics supports secure on-premises data processing, private AI development and custom AI/ML systems. The starting point, however, should be the business constraint rather than a preference for one deployment model.

Questions worth asking include:

• Which data cannot leave the organization?
• Which workflows must continue during an internet or provider outage?
• Which workloads require predictable latency?
• What level of model customization is needed?
• How quickly does the model need to improve?
• What operational capacity does the company have internally?

For one company, sovereign architecture may mean a fully disconnected system. For another, it may mean a provider-neutral application running across several managed services.

Both can be valid.

Can Your Company Actually Move Its AI?

A simple architecture review can reveal whether an AI product is portable or only appears portable.

Ask five questions:

1. Can we replace the primary model without rewriting the core business workflow?
2. Do we know where prompts, logs, embeddings and evaluation data are stored?
3. Does the AI capability have a defined service boundary and internal API?
4. Can selected workloads move to a private or local environment?
5. Can essential parts of the product continue operating when an external AI service is unavailable?

Three or more negative answers usually indicate a structural dependency.

That dependency may be acceptable for a prototype. It becomes harder to justify once the AI system handles customer data, influences business decisions or supports daily operations.

Where Allmatics Fits

Sovereign AI creates demand for infrastructure, models, legal frameworks and security controls. It also creates a large software engineering problem.

Someone still needs to build the application that connects company data, AI models and operational workflows.

Allmatics develops custom AI and software products across healthcare, HRTech, retail, logistics, aviation and other data-intensive industries. The work can include:

• AI architecture and product discovery;
• model integration and orchestration;
• custom web and mobile applications;
• private and hybrid AI deployment;
• document-processing pipelines;
• ERP, CRM, EHR and ATS integrations;
• role-based access and approval workflows;
• monitoring, audit logs and human review;
• modernization of existing platforms.

The aim is straightforward: keep the business process under the client’s control while allowing individual models and infrastructure components to evolve.

For teams moving an AI feature from pilot to production, an architecture review is often the useful first step. It maps model dependencies, data flows, integration risks and the components that should remain portable or private.

Talk to our AI/ML development team about the software layer behind your AI product.

FAQ

What is sovereign AI architecture?

Sovereign AI architecture is a system design that gives an organization defined control over its AI data, models, application logic, deployment environment and operational processes. The required level of control depends on the workload and regulatory context.

Does sovereign AI require an on-premises deployment?

No. A sovereign architecture can use public cloud, private cloud, local infrastructure or a hybrid model. The key issue is whether the organization understands and controls where data is processed, how the system operates and how easily components can be changed.

How can custom software reduce AI vendor lock-in?

Custom software can place models behind an internal API, keep workflow logic outside provider platforms, store logs and evaluation data under company control and support multiple models or deployment environments. This makes future migration more manageable.

The post Sovereign AI Architecture: Build Systems You Control appeared first on Allmatics.

If you run a retail platform, a commerce backend, or anything that touches checkout, agentic commerce has already arrived, even with a human still confirming most orders. The real question is narrower. Can your systems hand a purchase decision to software you don’t control, verify what that software was authorized to do, and still trust what comes out the other end?

From recommendation engines to agentic commerce

Retail AI used to stop at the suggestion. A recommendation widget surfaced a product, a chatbot answered a question, and a person decided what happened next. Agentic commerce removes that last step, at least in delegated scenarios. Once a shopper has pre-approved a merchant, a spending limit, and a timeframe, the agent doesn’t need a new approval for every routine purchase. It compares prices across sellers, checks the approved budget, and completes the transaction within those limits.

Adobe’s most recent traffic data shows why this stopped being a niche behavior. AI-referred traffic to US retail sites rose 393% year over year in the first quarter of 2026, TechCrunch reported. That traffic converted 42% better than regular traffic in March 2026, a full reversal from March 2025, when AI traffic converted 38% worse. Those AI-referred shoppers also spent 48% more time on site and generated 37% more revenue per visit. These visitors tend to arrive further along in the decision process than shoppers from traditional channels. That’s still AI-assisted discovery rather than fully delegated purchasing. But it shows a meaningful part of the shopping journey has already moved into AI interfaces, and retailers are starting to build for that reality instead of treating it as a dashboard curiosity.

Salesforce just made it official

On July 6, 2026, Salesforce took Agentforce Commerce out of pilot and into general availability. Treat that date as a signal more than a product update. The Shopper Agent now carries a customer from discovery through checkout on a retailer’s own storefront. The Buyer Agent handles B2B orders over WhatsApp and SMS without a portal login. The Merchant Agent runs back-office catalog and promotion work in plain language instead of a rules engine.

The distribution move matters more than the feature list. Salesforce confirmed native integration into ChatGPT this same month. Google Search’s AI Mode and the Gemini app follow later in the summer. That means a shopper’s AI agent, running in an interface a retailer doesn’t own, can complete a purchase on that retailer’s storefront directly. Salesforce has reason to move fast here. According to its own holiday season data, retailers running their own shopper agents grew sales 59% faster than retailers that sat out. AI-referred traffic converted at roughly eight times the rate of social traffic. When a platform this size ships this fast, “watch this space” stops being the right response.

Two sides of agentic commerce: buying and retail operations

Salesforce’s own product split is a useful map here. Shopper Agent works the customer-facing side: search, cart, checkout. Buyer Agent handles B2B ordering. Merchant Agent runs catalog and promotion work behind the scenes. Those are two different problems. Customer-facing agentic commerce is about a shopper’s agent finding and buying a product, still with a confirmation step in most flows today. Agentic retail operations is about a retailer’s own systems making decisions autonomously, on pricing, inventory, and storefront content, without a customer in the loop at all. Three patterns matter most on that operational side: dynamic pricing, autonomous inventory decisions, and session-level storefront personalization.

Dynamic pricing is the clearest case. A traditional pricing system runs on fixed rules: match a competitor minus 5%, hold a margin floor, open a promotional window on schedule. An agentic pricing system continuously optimizes price within predefined margin, compliance, and promotion guardrails, using live competitor, demand, and inventory signals instead of a static rule set.

Inventory management is where the dollar figures get concrete, and it’s the pattern with the clearest production evidence. Walmart reports that its Self-Healing Inventory system automatically reroutes overstock to the stores that need it, before the surplus becomes a write-off. It has saved the company more than $55 million so far. Walmart is now extending the system beyond the US into Costa Rica, Mexico, and Canada.

Personalized storefronts are the least visible pattern, but arguably the highest-leverage one where it’s deployed. An agentic system doesn’t work from pre-built customer segments. It rebuilds page layout, product order, and promotional content for each session in real time, and no marketer approves each configuration individually.

The agentic commerce architecture problem hiding underneath

Most omnichannel builds solved a coordination problem: keep the cart synced between mobile and desktop, match an in-store promotion to the website. That got fixed at the interface layer. The backend systems underneath, point of sale, ERP, warehouse management, CRM, mostly stayed separate. They only needed to look consistent to a human shopper. Nobody required them to talk to each other in real time.

Agentic commerce breaks that assumption. An agent making a pricing call needs live inventory data. An agent rebuilding a storefront needs current margin data by SKU. When those systems don’t share a common data layer, the agent acts on stale or incomplete information. A wrong decision made instantly is often worse than a slow one.

Unified commerce is the usual architectural answer. It’s a shared, real-time operational layer that gives every channel a consistent view of products, pricing, inventory, orders, and customer data. That doesn’t always require replacing every backend system, but it does require removing the conflicting versions of truth between them. It’s the prerequisite most agentic commerce vendor demos skip past. Manhattan Associates’ 2026 benchmark covered more than 400 specialty retailers across North America, EMEA, and Latin America. Only 7% qualified as unified commerce leaders, while 33% remained in the Basic category. The leaders posted nearly twice the growth rate of the least mature retailers. That gap is the real bottleneck, not the AI model choice.

What’s actually blocking most retailers from agentic commerce

The gap isn’t primarily budget. Most retailers are blocked by infrastructure decisions made five to ten years ago, decisions that were reasonable at the time.

Legacy point-of-sale systems are the most common chokepoint. They were built to record a transaction, not to feed a real-time data layer. Pulling live sales data out of a legacy POS without a full replatform usually means middleware, custom connectors, and ongoing maintenance. Every extra layer between the source system and the agent adds latency and another point of failure.

Fragmented data is the second blocker. Customer records sit in a CRM. Inventory sits in an ERP. Web behavior sits in an analytics platform. Margin data sits in a spreadsheet finance updates monthly. Commercetools’ research on agentic commerce readiness found that 81% of retailers say data quality issues affect business decisions at least sometimes, 45% sometimes and 36% often. An agent can’t reason across data that doesn’t connect. Unifying that data has to happen before any agent goes live, not after.

The third blocker gets the least attention: authorization. Who in the organization actually approved an AI system to change a price, or cancel a supplier order? At most companies, nobody has written down what an agent is allowed to do, under what conditions, or who signs off. Without that, even technically capable systems sit in pilot mode for months, because nobody wants to be the person who flips the switch.

A commerce agent needs more than API access

Giving an agent a live data feed is the easy part. The harder part, and the part most agentic commerce coverage skips, is proving afterward that the agent only did what it was supposed to do. That comes down to four things.

Identity: which agent made the request, and on whose behalf. Authorization: what spending limit, merchant list, or category it’s allowed to touch. Execution safeguards: idempotency so a retried request doesn’t double-charge or double-order, spending caps, and a rollback path. Audit: a record of which cart got approved, by what mandate, using what data.

This isn’t theoretical. Google’s Agent Payments Protocol builds a cryptographically verifiable chain between what the shopper asked for, what got approved, and what was actually charged. An Intent Mandate captures the shopping request and its limits. A Cart Mandate records the exact items and price. A Payment Mandate carries that approval to the payment network. Depending on the flow, the shopper approves in real time or authorizes the agent to act later within those predefined limits. Either way, the chain of signed mandates leaves an audit trail: what was requested, what the agent was allowed to buy, and what was paid. OpenAI’s Agentic Commerce Protocol takes a related approach. OpenAI never becomes the merchant of record. Each delegated payment token is capped at a specific amount and expiry, tied to a specific merchant, before the retailer’s own payment processor ever sees the request. Retailers building for agentic commerce need this same kind of scoped, logged authorization layer, not just an open API. That applies whether they’re exposing a storefront to someone else’s shopping agent or running their own pricing and inventory agents.

What building a POS-connected retail platform taught us

We covered the full build of a POS-connected customer engagement platform in an earlier case study, for a US retail startup with dealer and partner networks. The short version: no unified data layer, a POS replatform that was never on the table. We built a connector architecture on .NET, AngularJS, Google Cloud, and Kubernetes instead, surfacing POS data in near real time without touching the source system.

What that project made clear applies directly to agentic commerce. Partial stock updates. Delayed POS syncs. Two channels reporting different numbers at the same time. Those are the edge cases where agentic systems either hold up or fall apart.

Handing that same connector layer to an external AI agent, rather than only to your own dashboards, adds a new list of requirements. A machine-readable product catalog the agent can actually parse. A real-time inventory endpoint instead of a nightly sync. Scoped permissions per agent rather than one shared API key. An idempotent checkout path. A defined fallback for when the POS sync lags. A log of every action an agent took and why.

Where to start if you’re not starting from zero

The retailers making real progress this year didn’t launch a company-wide transformation program. They picked a narrow scope, proved it, and expanded from there.

Start with data unification before touching any agent. Map what data exists, where it lives, and what’s missing. Build or buy the connector layer that makes POS, inventory, and customer data available in one place. Treat that as the slower, unglamorous prerequisite it actually is.

Once that layer is stable, pick the highest-value, lowest-risk use case for a first agent: dynamic pricing in one category, or demand-driven replenishment for the top-selling SKUs. Define its scope narrowly. Build the human override before launch, not after an incident forces one. Run it against a control group for 60 to 90 days, and measure the result honestly before expanding.

Gartner projects that 40% of enterprise applications will include integrated task-specific AI agents by the end of 2026, up from less than 5% in 2025. Bain estimates agentic commerce will make up 15% to 25% of total US ecommerce sales by 2030, a $300 to $500 billion market. McKinsey’s global estimate runs as high as $3 to $5 trillion by the same year.

That’s a lot of money chasing a problem most companies haven’t solved yet. Data and governance work, done early and without fanfare, is what separates the two outcomes. One retailer scales an agent. The other spends 2027 explaining why the pilot never launched.

How Allmatics approaches this

Our Web/Mobile Development and AI/ML Development work covers exactly this layer. That means connector architecture exposing POS, inventory, and customer data in real time without a forced replatform. It also means agent scoping that separates what a system can suggest from what it’s authorized to execute on its own. We wrote up the full POS-connected retail SaaS build if you want the detail behind the architecture referenced above. Our broader view on retail and e-commerce infrastructure is a useful starting point if you’re earlier in scoping this.

If you’re deciding where an AI agent should sit in your retail stack, get that decision right during product discovery. It’s cheaper than fixing it after the agent is already live against production data.

Frequently Asked Questions

What is agentic commerce? Agentic commerce is retail AI that acts on a shopper’s or a business’s behalf: comparing options, adjusting prices, managing inventory, or completing a purchase, rather than only recommending a product for a human to act on. It requires real-time data access and defined authority to execute, not just to suggest.

Is agentic commerce the same as a shopping chatbot? No. A chatbot answers questions and waits for a human decision. An agentic system takes the next step: executing a price change, a reorder, or a checkout, within limits a business defines in advance.

What does a retailer need before deploying an agent? A unified data layer connecting POS, inventory, and customer data in real time, a narrowly scoped first use case, and an explicit governance rule for what the agent can do without human approval. Skipping the data layer is the most common reason pilots stall.

The post Agentic Commerce in 2026: What Retail Systems Need Before AI Can Buy appeared first on Allmatics.