Workflow App For UAE Warehouse Consumer Marketplace

Industry

Transportation & Logistics

Geography

Dubai, UAE

Cooperation Period

6 weeks

About the Client

Cargoz FZE runs an on demand warehouse storage marketplace in the United Arab Emirates. Headquartered at Dubai Silicon Oasis, the platform matches businesses that need storage with warehouse operators across 5 emirates and 25+ sub locations, from JAFZA and Jebel Ali to Hamriyah Free Zone and ICAD. Cargoz’s marketplace covers general cargo, dangerous goods, chemical, food grade, open yard, AC, dry, and cold storage, with per pallet or per SQFT rentals starting at 50 SQFT.

The consumer marketplace is the visible surface. Behind it, Cargoz operates a warehouse partner network, a set of storage companies whose employees process the inbound and outbound shipments that Cargoz’s customers book on the platform. Cargoz reports 1M+ SQFT under active use, 2000+ customers, and enterprise customer counts that include Fairmont, Hilton, JA Resorts, Larsen & Toubro, and Cambridge University Press. Every booking creates warehouse side operational load. The partner company receiving a booking has to log the inbound, allocate space, run outbound cycles on request, and report any damages back through the marketplace.

Cargoz engaged Clixlogix to build the Cargoz Champion Application, a mobile workflow tool for the employees of its warehouse partner network. The Application is a distinct product from the consumer marketplace. It sits behind it as the operational surface that keeps every partner warehouse’s daily execution moving. The Cargoz Champion Application is live on the Apple App Store and Google Play Store under Cargoz’s own developer accounts.

Challenge

Cargoz’s CTO was carrying backend architecture, API design, and platform infrastructure at the same time as the mobile workflow app came into scope. A public partner network was expecting the app. Cargoz had the Figma designs, an in house backend engineer building the APIs, and a firm commitment to publish on both mobile stores under its own developer accounts. 3 constraints defined the engagement scope.

A mobile workflow app for warehouse partner employees, on a backend that was still being redesigned.

The Cargoz Champion Application had to move the daily operations of warehouse partner staff onto a mobile surface. Field employees needed to process inbounds, process outbounds, run damage reporting flows with photo capture, and earn Cargoz Coins for completing tasks and referring new warehouses to the network. Cargoz owned the product vision. What Cargoz did not have was a React Native developer plugged into their engineering workflow. Bringing on a traditional fixed price vendor would have imposed a project management overhead on the CTO the engagement was designed to eliminate.

An API surface that was moving under the frontend build.

At the point the frontend engagement kicked off, only the Login and Logout endpoints were operational. The Cargoz backend team was mid flight on an API redesign, transitioning authentication from session identifiers to JSON Web Tokens for the entire request surface. Swagger documentation existed as a commitment on the roadmap. A fixed price, fixed scope engagement would have stalled here waiting for API stability. Cargoz needed a delivery approach that could hold frontend velocity while the backend rearchitected.

A restricted access consumer app that had to publish to both stores under Cargoz’s own developer accounts.

The app was restricted by design to employees of companies signed up as Cargoz warehouse partners, which raised Apple’s standard review questions about limited access apps and required careful handling of the review questionnaire. Both stores also required a partner who owned the technical build, the review responses, and the resubmission cycle end to end. Cargoz needed the app live on iOS and Android inside Cargoz’s own Apple and Google developer accounts, with the publishing responsibility handled by Clixlogix.

Approach

Clixlogix structured the engagement around a single delivery premise the team carried across every workstream. Direct Resource Engagement treated the frontend build as a resource Cargoz’s engineering team could direct in the same way it directed its own backend engineer.

Building the engagement this way meant the frontend and backend could adapt to each other’s decisions inside the same sprint. When the API surface changed shape mid build, the developer absorbed the change alongside the person making it. When the CTO wanted to change a workflow card, the change happened on the same task board the developer was reading. Every architectural pivot the backend needed to make happened without triggering the scope change conversation a fixed price vendor engagement would have required.

Fig 1 – Direct Resource Engagement Model

The engineering coherence sat below every workstream. Each new capability Clixlogix built inherited the same task discipline, the same code review posture, and the same channel of feedback from the Cargoz side. There was no handoff meeting between the frontend developer and the backend engineer. They worked from the same feature list all the way through delivery.

Consulting Insight

When the client's engineering surface funnels through one person, the CTO carrying backend, API, and infrastructure at the same time, a fixed price engagement quietly fails. Every process the vendor introduces, kickoff meetings, status reports, scope change conversations, steals hours from the critical path person and slows the whole build. On this shape of account, the vendor's process is itself the delivery risk. The pivot is engineering the engagement so the client never has to look at the vendor as a coordination surface at all.

Solution

Clixlogix structured delivery across 4 workstreams running against the engagement window, each completing a production commitment end to end.

Direct Resource Engagement Foundation

The team engineered the delivery model as the foundation every workstream would depend on. The engagement started with a consultation cycle and delivery planning phase focused on the client’s engineering topology, calendar constraints, task board setup, and engineering channels. The consultation surfaced 3 requirements. The client wanted minimal vendor management overhead, a developer who plugged into the existing task board and engineering channels, and a delivery cadence the CTO could observe without needing to attend meetings. Clixlogix calibrated the delivery model to those requirements before the first sprint opened.

A Clixlogix React Native developer embedded inside Cargoz’s internal engineering team, known as Team Mastara, working alongside Cargoz’s backend engineer. Coordination ran through the surfaces Cargoz already used internally. Task cards lived on the client’s task board. Real time engineering conversation moved into the client’s engineering channels within the first 2 weeks of the engagement. Clixlogix’s delivery lead owned program management and communication, freeing Cargoz’s leadership from the coordination overhead a traditional vendor engagement would have imposed.

Phase discipline held visibly across the engagement. The Cargoz CTO could see, on any given day, which task was ahead or behind, which had unresolved dependencies, and which had moved to the next phase. Delivery variance surfaced and resolved inside the phase where it originated. As the project moved into later iteration, Clixlogix rotated a second engineer into the direct engagement seat, holding the delivery model constant across the team change.

For a Cargoz employee working on the platform, this meant an outside developer participated in the same daily decisions as the internal backend engineer, on the same terms. For Cargoz’s leadership, it meant zero project management overhead on their side. The Clixlogix delivery lead absorbed the coordination burden that a traditional vendor engagement would have imposed on the CTO.

Frontend Build Absorbing a Moving Backend Redesign

With only Login and Logout APIs operational at frontend kickoff, Clixlogix built the React Native UI against the Figma designs and stub contracts derived from the API redesign specifications the Cargoz backend team shared through the engineering channels. The team completed frontend development on every unauthenticated screen in parallel with the backend API redesign. When the Cargoz backend team published the Swagger and ReDoc documentation mid cycle, Clixlogix wired the completed screens into live endpoints in sprint. An early API demonstration confirmed working Login, Logout, Survey Questions, and Stock Transfer Information endpoints, with UI ready for each one.

Mid project, the Cargoz backend team announced the transition from session identifiers to JSON Web Tokens for the full authenticated API surface. In a typical vendor engagement, this would have triggered a scope change conversation, a reestimate, and a delivery slip. In the Direct Resource Engagement model Clixlogix and Cargoz were running, the embedded developer absorbed the migration on the frontend inside the same sprint the change was announced, keeping the UI contract stable and delivery on schedule. This is the kind of mid flight architectural change that lives or dies on how tightly the frontend and backend engineers work together. The shared engineering channels and shared task board made it a same sprint change.

Consulting Insight

The default assumption in a React engagement is that the frontend is downstream from the API. When the API is being redesigned live, that assumption stalls the build. The pivot is treating the Figma as the actual contract and letting the API converge to it in its own sprint window. This inverts the dependency without renegotiating scope. Every screen ships against a design contract that will not change under it, and the API arrives at the shape the UI already expects.

For a warehouse partner employee eventually using the app, this meant every unauthenticated screen was ready when the authenticated endpoints came online. There was no version 0.5 shipped with placeholder screens. For Cargoz, it meant the backend redesign did not push the mobile launch. The frontend and backend converged on the same production release.

Damage Reporting Workflow with Multi Photo Asynchronous Upload

The damage reporting flow was the operational heart of the Cargoz Champion Application. Field employees moving through inbound and outbound cycles at the warehouse needed to capture and upload multiple photos as part of each workflow card. UAT surfaced a latency issue on the photo upload flow, worse when multiple photos were queued on a single card. Clixlogix rebuilt the upload as an asynchronous background thread operation, decoupling capture from server confirmation. Field employees could progress through subsequent workflow cards while uploads completed in the background. The fix landed in the following build cycle alongside other UAT corrections.

Fig 2 – Async Photo Upload Data Flow

Consulting Insight

On a field workflow app, the metric that matters is how the app behaves when the network is slow, when multiple artifacts are captured in a row, and when the workflow pace is set by the user's tempo. The design contract has to let the user continue while server confirmation completes in the background. The pivot is designing the response contract around the user's tempo, with server confirmation as an asynchronous background event.

For a warehouse employee running through their damage reporting cycle, this meant tapping through workflow cards continuously without waiting for the previous card’s upload to finish. The workflow speed followed the field employee’s tempo, with server confirmation completing in the background. For Cargoz, this shaped one of the highest frequency workflows in the app around real field usage conditions, which matters when the app is deployed across a partner network of independent warehouse teams.

Dual Store Publishing Under Cargoz’s Own Developer Accounts

Cargoz operated its own Apple App Store account and set up a Google Play Console account during the delivery cycle. Clixlogix owned the submission and review cycle on both stores, worked with Cargoz on the responses to Apple’s review questionnaire about restricted access apps (Cargoz Champion is limited to employees of Cargoz warehouse partners), and iterated through review feedback on both stores until each went live. iOS shipped to production first, Android shortly after. Both apps installed under Cargoz’s own brand from the store, with future updates, feature releases, and analytics staying inside Cargoz’s own developer accounts.

Following the Android publish, Clixlogix retained ownership of the app under a 2 week free maintenance window covering both stores, giving Cargoz a stable stabilization period. Support beyond that window remains available on a resource on demand basis, tied to the same Direct Resource Engagement model that carried the original delivery.

For a warehouse partner employee, the app installed from the store under Cargoz’s own brand, with no visible vendor attribution. For Cargoz, the account ownership meant future updates, feature releases, and analytics stayed inside Cargoz’s own developer accounts. The maintenance window gave the platform a stable stabilization period after launch. No new engagement negotiation was needed for typical post launch touch ups.

Results

The Cargoz Champion Application shipped on schedule and remains live on both stores. For Cargoz, the engagement delivered 5 material business outcomes.

React Native Workflow App Shipped to Both Stores

Production apps live on the Apple App Store and Google Play Store under Cargoz's own developer accounts. iOS shipped to production first, Android shortly after. Both apps remain in production, serving Cargoz's warehouse partner network across the UAE.

One React Native Codebase Serving Both Platforms

A single React Native codebase serves both iOS and Android production builds. Native photo capture, background thread photo upload, and workflow card UI share their source across both platforms. Every future update ships to both stores from the same source, keeping the maintenance surface at one codebase for the life of the app.

6 Weeks of Active Build End to End

6 weeks of active engineering carried the app from kickoff to both stores live. The engagement stayed inside a single continuous window with no gap phases, no vendor selection reset, and no re scoping conversations. The direct resource model meant the client's CTO never had to reopen the scope discussion mid delivery.

Backend Redesign Absorbed Inside a Single Sprint

The Cargoz backend team moved from session identifiers to JSON Web Tokens across every authenticated endpoint in the middle of the frontend build. Clixlogix executed the migration on the frontend inside the same sprint. The UI contract remained stable and the delivery cadence held. No scope change conversation, no reestimate, no delivery slip.

Zero Hotfixes At Production Sign Off

The client ran UAT cycles across every build phase, and every UAT issue got named, tracked, and resolved inside the following build cycle. At production sign off, the remaining open items were 2 non blocking issues both slated for a subsequent version update on the client's decision. The production build shipped on both stores without a hotfix.

Technologies and Tools

Layer	Stack
Frontend	React Native for cross platform mobile delivery from a single codebase serving both iOS and Android, native photo capture on both platforms, background thread photo upload, workflow card UI shared across inbound, outbound, and damage reporting flows
API	JSON Web Token authentication on the client integration side, absorbed mid project when the backend migrated from session identifiers, Swagger and ReDoc consumption during API integration, stub contracts derived from the client API redesign specifications during the frontend build phase
Delivery	Jira for task management inside the Cargoz engineering team, real time engineering coordination between the Clixlogix developer and the Cargoz backend engineer on the client existing engineering channels, Direct Resource Engagement model with a Clixlogix developer embedded on the client task board
Distribution	Diawi for Android beta distribution, TestFlight for iOS beta distribution, Apple App Store Connect for production iOS publishing under Cargoz own Apple developer account, Google Play Console for production Android publishing under Cargoz own Google developer account

Services Delivered

Digital Engineering, Mobile App Development, Quality Assurance & Testing, Consulting Service

Team Composition

Delivery Lead, Mobile Engineers (iOS + Android), QA Engineers, Project Manager

Have a question for our team or need help with your project?

Our team can share client references, scope your project, and answer any question about your delivery.

Related Case Studies

More engagements where our delivery teams shipped similar outcomes for clients across industries. Read on for context on the patterns we reused, the trade offs we navigated, and the metrics that landed in production.