From Desktop to Browser: Why We Rebuilt RRMS for the Web
Our original platform ran as a Windows desktop application. Moving to a browser-based architecture eliminated installation friction, enabled real-time collaboration, and opened the door to tablet-first warehouse workflows.
The first version of RRMS was a Windows desktop application. It was built that way for a reason: cargo handlers needed something fast, offline-capable, and deployable on the warehouse PCs they already had. At the time, a desktop app was the right call.
Two years later, it was clear the architecture was becoming the platform's biggest constraint. Not because the software was bad — it worked — but because every advantage of a desktop model was starting to cost more than it saved.
The installation problem
Deploying a desktop application in a cargo warehouse environment is harder than it sounds. Airport IT infrastructure is often managed centrally. Handlers may not have administrator rights on their assigned machines. A new workstation requires a manual installation visit. A version update requires another visit, or at minimum a careful auto-update process that does not interrupt an active shift.
We built an auto-updater. It worked. But we were spending engineering time on a problem that browser-based software simply does not have. Every user is always on the latest version. There is nothing to install. A new workstation is ready the moment someone opens a browser and logs in.
The shared data problem
The desktop application stored data locally and synced periodically to a central database. This meant that if two agents checked the same AWB on different machines simultaneously, they were working from slightly different snapshots of reality. For most tasks this was acceptable. For time-sensitive operations like ULD demurrage monitoring or active container alerts, it was not.
Moving to a browser client calling a live API eliminated this category of problem entirely. Every screen reflects the current state of the database. An overdue ULD flagged by the system appears on every logged-in session simultaneously. A cargo acceptance recorded by one agent is immediately visible to another in the overview.
The tablet opportunity
One thing the desktop model could not support at all was tablet-based workflows. Cargo warehouse operators move around. They accept shipments at a dock, check containers in Cool Cell, inspect ULDs on the ramp. A fixed PC workstation requires them to walk back to a desk to record what they found.
A browser application works on any device with a screen. The same interface that runs on a supervisor's dual-monitor desk runs on a shared tablet mounted near the Cool Cell door. Role-based access controls mean each device can be logged in with the appropriate operator account, showing only the modules relevant to that location.
What we kept from the desktop model
The move to the browser was not a rewrite for its own sake. The workflow logic — how acceptance checklists work, how ULD holding rules are applied, how audit packs are structured — came directly from the desktop version. We rebuilt the delivery mechanism, not the domain knowledge.
The result is a platform that is faster to deploy, easier to maintain, and usable anywhere — without losing the operational depth that cargo handlers actually need. No compromises on compliance. No simplified feature set to make the browser version work. Just the same toolset, accessible from any device, always up to date.
If your operation is still running cargo management software that requires an installation visit, it is worth asking whether that friction is costing you more than you realise.