The Device in a Worker’s Hand Is Now the Enterprise: Bass Pro Shops’ Chandra Kiran Movva on Building Retail’s Invisible Infrastructure

Honestly, it has changed completely.

When I started, a mobile app felt like a finished product on its own. You built the screens, connected them to an API, and shipped. That world has changed. The phone or handheld is no longer the endpoint. It is one node inside a much larger system.

On a retail floor, a single device might be a payment terminal, an inventory scanner, an identity token, and a data collection point all at once. It also has to stay synchronized with backend systems, processors, and other devices.

That forces a different mindset. You stop thinking only like an app developer and start thinking like a systems engineer. You are designing for thousands of devices, unreliable connectivity, security requirements, and failure cases where a problem can have a direct business impact.

The reliability bar is much higher than it is for many consumer applications. That is the transition I have experienced, from building applications to building infrastructure that happens to run on a mobile operating system.

Picture the stores. Bass Pro Shops and Cabela’s operate large locations, and a customer might be standing in the middle of a boat department or a fishing aisle, nowhere near a traditional register.

The business needed a way to complete a secure card payment anywhere on the sales floor, using a rugged handheld device, without compromising the security requirements associated with payment processing.

That is a difficult engineering problem because payments are unforgiving. There is very little room for error.

ZebraPay is a custom Android payment gateway that I architected to run on Zebra handheld devices and connect with Fiserv for secure card processing. In effect, it allows a handheld device to function as a point of sale.

Today, it runs on more than 3,000 devices across 174 stores and has supported more than $40 million in transactions.

But the number I care about most is not the transaction value. It is whether associates trust the system enough to use it during a busy shift. Reliability matters because a failed transaction affects both the customer and the associate trying to complete the sale.

Getting there involved reworking parts of the legacy kiosk codebase, strengthening the security model, and building capabilities that customers never see. There is a force update mechanism so devices cannot continue running an unapproved version of the application. There is single sign on for secure associate authentication. I also worked on device power management so the hardware behaves predictably throughout a long retail shift.

The threat model changes as soon as a payment device starts moving around the store.

In a traditional point of sale environment, the terminal sits behind a counter, is connected to a controlled network, and has a relatively contained physical environment. When you hand an associate a payment device, the device connects over Wi Fi, it is physically accessible, and it shares an operating system with other enterprise applications.

For ZebraPay, I approached security in layers. Card data is encrypted at the hardware level before it reaches the application layer, and communication with Fiserv is secured end to end. We also use single sign on through Blue Fletch so authenticated associates on enrolled devices can initiate transactions.

The force update mechanism also serves as a security control. If a device is not running an approved version, the application does not run. That provides a way to enforce security updates across the fleet rather than relying on every individual device to be updated manually.

The operational side is equally important. Some devices may be offline, some may be in the middle of a transaction, and others may have very little battery remaining at the end of a shift.

I designed the update and lifecycle system to account for those conditions through staged rollouts, graceful deferral during transactions, and enforcement after a defined grace period. There is also a battery and power management layer designed around the Zebra hardware.

At this scale, device management becomes part of the application architecture. You can have a well designed payment application, but if you cannot ensure that every device is running the right version, configured correctly, and reporting its health, the overall system is not reliable.

The industries are different, but the underlying engineering problems often have more in common than people expect.

At Schneider Electric, I was the sole Android developer on the Wiser Air and Wiser One smart thermostat platform. The system controlled thermostats, smart bulbs, and blinds using the Open Connectivity Foundation protocol.

At Ford, I worked on the AppLink library that allows a mobile application to communicate with an in vehicle infotainment system.

Earlier, at Phunware, I worked on indoor mapping and location SDKs. One of the key capabilities was turn by turn indoor navigation, where Bluetooth beacons and Wi Fi signals were used because GPS does not work reliably indoors.

In each environment, software had to interact with physical devices and real world conditions. A connectivity problem, sensor issue, or software failure could affect what a person was actually trying to do.

Indoor navigation taught me to think carefully about noisy sensor data and the consequences of incorrect information. Connected vehicles taught me about interoperability and communication with hardware. Smart home IoT introduced another set of challenges around protocols and asynchronous data.

Those experiences created a common discipline around reliability. Whether it is a thermostat, a vehicle system, or a payment terminal, the software has to work with hardware that you do not completely control.

I try not to treat architecture as a matter of ideology. It is about engineering tradeoffs.

At Schneider Electric, the Wiser platform used MVP with RxJava and Dagger 2. That worked well for an IoT application handling complex asynchronous data streams from the OCF protocol.

At Bass Pro, I moved toward MVVM with Jetpack because the retail applications required tighter integration with Android’s lifecycle management. MVVM also provides a cleaner way to manage application state across configuration changes.

One of my papers focuses specifically on MVVM patterns for enterprise Android kiosk applications. Kiosks have unusual constraints. They can run for long periods without restarting, they may handle sensitive information, and an application failure can affect a transaction.

The architecture therefore has to be defensive.

Ultimately, the right pattern is the one your team can understand, your tests can exercise, and your system can recover from when something goes wrong. I have seen overly complicated architectures create more problems than they solve.

The problems I work on are not always well documented.

There is a great deal of material about consumer applications and cloud backends, but less discussion about mobile systems operating as critical infrastructure in the field.

I wanted to document some of the engineering patterns I was seeing in practice.

I have written about enterprise Android kiosk architecture, payment gateway design for IoT handheld devices, security policy enforcement across large retail fleets, connected vehicle integration, and OCF implementation for smart home IoT, among other subjects.

Several of those papers have been cited by other researchers, which has been encouraging.

Writing also changes the way you think about a problem. When you have to explain an engineering decision clearly enough for peer review, you have to examine your assumptions and justify the choices you made.

It also gives other engineers and researchers something to build on instead of having to solve the same problem from scratch.

It changes almost everything.

With a few thousand users, you can ship quickly and address edge cases as they appear. Once an application reaches a much larger audience, every edge case becomes somebody’s experience.

Small error rates that might seem insignificant at low scale can turn into a significant operational burden.

At Bass Pro, the applications support millions of users across e commerce, loyalty programs, and in store associate workflows. That scale changes the engineering culture.

You invest more in automated testing, staged releases, monitoring, and instrumentation that tells you what is happening on devices you cannot physically access.

You stop thinking only about the application and start thinking about the fleet.

That experience has also influenced my technical writing. When a design decision affects a large number of users or a significant business operation, it is worth understanding why the decision was made and documenting the reasoning behind it.

I take it seriously because the quality of a system depends heavily on the judgment of the people building it.

At Bass Pro, I participate in peer code reviews, mentor developers, and help design coding exercises and technical interviews used to evaluate candidates.

What I look for is not simply clever code. I want to understand how someone thinks about failure, security, maintainability, and the person who ultimately depends on the system.

That matters particularly when software is handling real transactions across thousands of devices.

Evaluating other engineers has also made me more conscious of how I evaluate my own work. Good engineering is often less about finding the most complicated solution and more about making the right tradeoff.

I am grateful for the recognition because it has allowed me to connect my engineering work with a broader technical community.

I received the International Universal Innovators Leadership Award in London in June 2026. The recognition focused on my work at the intersection of mobile engineering and IoT and its contribution to digital transformation.

The Fellowship of the Soft Computing Research Society represents another part of my professional work. My involvement with the research community has given me an opportunity to contribute beyond the systems I build in my day to day engineering role.

Increasingly, my role is moving toward setting architecture and technical standards that other engineers build against, while also sharing that work through technical writing and speaking.

For me, leadership in engineering is not only about what you personally build. It is also about creating systems, standards, and knowledge that remain useful to other people.

The next step for the infrastructure I have been describing is for it to become more capable of making decisions instead of simply responding to instructions.

Today, a handheld device largely executes what a person tells it to do. The next generation could anticipate problems.

A device could flag an unusual transaction before it is completed, guide an associate through an unfamiliar workflow, or monitor its own fleet health and identify issues before they become operational problems.

I have been deliberately building my knowledge of generative AI and agentic tooling, including hands on work with tools such as Claude Code and GitHub Copilot.

The direction makes sense to me because it connects several parts of my career. I started with applications, moved into connected devices, and increasingly work on systems where software interacts with physical infrastructure.

The engineering principles do not change. Reliability, security, and trust remain essential.

What changes is where intelligence is placed.

One of my papers explores machine learning optimization for warehouse operations, which is an example of how AI can interact with physical infrastructure. That is the direction I want to continue exploring, particularly where AI can improve real systems without compromising reliability or trust.

Start by learning to think about failure before you think about features.

In a consumer application, a crash might result in a bad review. In enterprise infrastructure, a failure can mean a lost transaction or an associate standing in front of a customer with a blank screen.

The consequences change the way you design.

Second, become comfortable with hardware. Read the specifications for the device your software runs on. Understand its battery behavior, connectivity, security capabilities, and operating constraints.

Many mobile developers naturally think of the device as an abstraction. In enterprise IoT, the device is part of the architecture.

And finally, publish your work.

The enterprise mobile and IoT space is under documented partly because the engineers working on these systems are busy building them.

If you solve a difficult problem, document it. Writing forces clarity, builds a record of what you learned, and gives the next engineer a starting point.

The field moves forward when practical engineering knowledge is shared.