How to Build a Warehouse Mobile App Connected to Your ERP

Your warehouse staff do not sit at desks. They walk aisles, drive forklifts, pick orders, pack boxes, and load vans. Yet the ERP tools they are issued with were designed for someone sitting at a workstation with a mouse, a keyboard, and fifteen minutes to drill through menus. Shrinking Business Central, OrderWise, or Sage 200 onto a phone screen does not make it a mobile app. It makes it a small, frustrating desktop interface.

This mismatch costs real money. Pick errors, cycle count inaccuracies, delayed dispatches, and the quiet creep of paper-and-spreadsheet workarounds that nobody logs but everybody relies on. A purpose-built warehouse mobile app, connected to your ERP through its API, eliminates those costs. Here is how to think about building one, what the architecture looks like, and what the trade-offs actually are.

The core problem: desktop UIs for task-oriented workers

ERP interfaces are designed around data entities: Sales Orders, Purchase Orders, Items, Customers. You navigate to the entity, find the record, perform an action. That is a document-centric workflow. Warehouse work is task-centric. A picker does not care about the Sales Order entity. They care about: "What is the next item on my pick list, where is it, and where does it go?" A receiving operative does not care about the Purchase Order entity. They care about: "Which PO just arrived, which items are on it, and where should I put them?"

When you force a task-oriented worker into a document-oriented interface, three things happen. First, they slow down — every action requires navigation rather than a single tap. Second, error rates increase because the interface presents data in a format that does not match the physical workflow. Third, and most predictably, your team builds workarounds: paper pick lists transcribed from a shared terminal, stock counts maintained in a spreadsheet behind the office desk, deliveries tracked on a whiteboard.

Those workarounds are not laziness. They are rational responses to an interface designed for the wrong user. A warehouse mobile app reverses this: it puts the task first and pulls the relevant ERP data into a single, focused screen.

What a good warehouse mobile app actually does

There is no shortage of "warehouse apps" on the market. Most are generic inventory management tools with a barcode scanner bolted on. A genuinely useful warehouse mobile app, connected to your ERP, does the following:

Barcode scanning with ERP validation

Not just scanning a barcode and recording it locally. Scanning a barcode that hits your ERP inventory data in real time, validates the item exists at the expected location, and updates stock quantities on the spot. If the picker scans the wrong item, the app flags it immediately — not at the dispatch bay when the customer rings.

Task-oriented work queues

The app presents each user with a list of tasks assigned to them: Pick Order #10452 (5 items, Aisle 4). Receive PO #8821 (12 items, Bay 7). Put away to Location B-12. Cycle count Zone C. Each task is a card with a single tap to start, clear instructions, and a confirmation step at completion. No menu navigation. No guessing what to do next.

Live stock lookup

A warehouse manager or sales desk needs to answer "do we have 50 units of part ABC-001 in stock?" in under five seconds. The app provides a search-driven stock lookup that returns bin location, available quantity, reserved quantity, and on-order quantity from the ERP directly. No need to log into a terminal and navigate through three screens.

Signature and proof-of-delivery capture

For dispatch and delivery workflows, the app captures a signature on screen, timestamps it, and attaches it to the relevant shipment record in the ERP. No more filing paper PODs or chasing lost delivery confirmations.

Offline capability

Warehouses are not famous for perfect cellular coverage. Concrete walls, steel racking, and low-roof extensions create dead zones. A good mobile app queues actions locally when the network drops and synchronises them to the ERP when connectivity returns — with conflict detection to prevent the "same item picked twice" scenario.

Architecture: device to ERP in three layers

Building a warehouse mobile app that talks directly to your ERP database is a bad idea. ERP databases are not designed for high-frequency read-write operations from dozens of mobile devices, and direct database access introduces security and integrity risks that no sensible ops director should accept. The correct architecture uses three layers:

+------------------------+      +---------------------------+      +---------------------+
|                        |      |                           |      |                     |
|   MOBILE DEVICE        |      |   MIDDLEWARE / API GATEWAY|      |   ERP               |
|                        |      |                           |      |                     |
|  React Native / Flutter|      |  Node.js / .NET / Python  |      |  BC / OrderWise /    |
|  app with offline      | ---> |  - Auth (OAuth 2.0)       | ---> |  Sage 200            |
|  queue (SQLite)        |      |  - Request validation     |      |                     |
|                        |      |  - Transform & map data   |      |  REST API / SOAP /   |
|  Barcode scanner       |      |  - Rate limiting          |      |  Web Services        |
|  GPS / camera          |      |  - Offline sync logic     |      |                     |
|  Signature capture     |      |  - Logging & audit trail  |      |                     |
|                        |      |                           |      |                     |
+------------------------+      +---------------------------+      +---------------------+
         |                                |                                |
         |   Offline queue                |   Business logic               |   Data authority
         |   (IndexedDB / SQLite)         |   Sync engine                  |
         |                                |                                |

Layer 1 — Mobile device: This is the user-facing application. It handles the UI, barcode scanning via the device camera, GPS for route tracking, and local storage for offline operation. The device never talks to the ERP directly. It communicates only with the middleware layer via REST or WebSocket, using short-lived JWTs for authentication.

Layer 2 — Middleware / API gateway: This is where the intelligence lives. The middleware translates mobile app requests into ERP API calls, handles authentication with the ERP system, manages the offline sync protocol, applies business rules that the ERP itself cannot enforce (sequence validation, duplicate scan detection), and maintains an audit log. It also provides rate limiting to prevent the ERP API from being overwhelmed during peak usage.

Layer 3 — ERP: This remains the single source of truth. Stock quantities, order statuses, customer records, and pricing all live in the ERP. The mobile app reads from and writes to this data entirely through the middleware, never directly. The ERP never knows a "mobile app" exists — it sees standard API calls from a trusted client.

Offline-first design

The offline capability deserves its own explanation because it is the feature most commonly implemented badly. An offline-first design does not mean "cache some data and guess." It means:

• Local store: The device maintains a local copy of the data it needs for its current tasks — pick lists, stock lookups for the aisles the user is working in, customer details for deliveries. This data is fetched from the middleware when connectivity is available and cached in SQLite or IndexedDB.
• Action queue: Every user action (scan, pick confirm, put-away confirm, signature capture) is written to a local queue with a unique ID, timestamp, and status. If the network is available, the queue drains to the middleware immediately. If not, it waits.
• Conflict resolution: When the queue drains after a network outage, the middleware checks each action against the current ERP state. If a stock item was picked by two devices while offline (edge case, but it happens), the middleware flags the conflict and rejects the second action. The user sees "Item already picked — check with supervisor" rather than a silent data mismatch.
• Idempotency: Every write action carries a unique ID. If the device sends the same action twice (network blips during sync), the middleware recognises the duplicate ID and returns success without applying the action again.

ERP API realities: what each platform provides for warehouse operations

Not all ERP APIs are created equal. The warehouse operations you can support depend heavily on what your ERP exposes at the API level. Here is a fact-based look at the three most common platforms among UK manufacturing and distribution SMEs.

Dynamics 365 Business Central

Business Central exposes a comprehensive REST API (via the v2.0 OData endpoint) that covers most warehouse entities: Items, Stock, Warehouse Entries, Warehouse Shipments, Warehouse Receipts, Sales Orders, Purchase Orders, and Posted Documents. Authentication uses OAuth 2.0 via Microsoft Entra ID, which integrates neatly with your existing Microsoft 365 SSO.

What it handles well: stock lookups, order retrieval, creating warehouse shipments and receipts, posting pick lines. The API response times are generally sub-200ms for single-record operations. What is trickier: Business Central's warehouse management system (WMS) features require specific configuration and licensing. If you use "basic" warehouse configuration (location codes only, no directed put-away/pick), the API surface is narrower. You need at least the "Basic" warehouse licence per user for full API-driven warehouse operations.

One practical limitation: Business Central does not expose a real-time push API. Your middleware must poll for status changes or use webhooks via Power Automate or Azure Service Bus. This adds latency to real-time updates unless you architect around it.

OrderWise

OrderWise exposes a SOAP-based web service API and, more recently, a REST API (v2). The SOAP API is fully featured but verbose — every request requires a detailed XML envelope. The REST API is cleaner but still covers a subset of the SOAP API's capabilities. Authentication uses API keys passed in headers.

For warehouse operations, OrderWise's API supports: inventory lookups (quantity, location, serial numbers), sales order creation and retrieval, warehouse movement creation, pick note generation, and goods receipting. OrderWise's native mobile app (OrderWise Mobile) already covers basic scanning and picking, so the question is whether you need a custom mobile experience or the stock app suffices. Where a custom app wins is in tailoring the workflow to your specific process, integrating with non-OrderWise systems (carrier APIs, label printers), and controlling the UI/UX for your staff.

One challenge: OrderWise API documentation is not publicly available without a partner login. Rate limits are not clearly documented, which means you should build middleware with adaptive backoff. SOAP payloads for warehouse operations can exceed 50KB per request — fine on WiFi, noticeable on 4G.

Sage 200

Sage 200 exposes a REST API via Sage 200 API (formerly the "Sage 200 Web API") and, for older deployments, a COM-based API that requires on-premise middleware. The REST API covers: Stock Items (with warehouse bins), Sales Orders, Purchase Orders, Customers, and Suppliers. Authentication uses OAuth 2.0.

For warehouse operations, the Sage 200 API handles stock lookups, stock movement recording, despatches, and goods received notes. What it does not handle well: warehouse task assignment, pick list generation, or directed put-away. These are not exposed by Sage 200's API, meaning your middleware must implement the logic to convert a sales order line into a pick task, assign it to a user, and track its completion independently. The ERP only sees the final stock movement.

This is not necessarily a problem — it is precisely the kind of business logic that belongs in your middleware layer anyway. But it is worth knowing upfront because it affects build effort. Sage 200 API calls are also rate-limited to approximately 60 requests per minute per tenant, which is fine for a single warehouse but may require optimisation for multi-site deployments.

Quick comparison

Tech stack options: what actually works

Three frameworks dominate warehouse mobile app development today. Here is an honest comparison for a UK SME context — not what the marketing materials say, but what the reality looks like after deployment.

React Native

Best for: Teams with existing JavaScript/TypeScript expertise, or apps that need to run on both iOS and Android from a single codebase.

React Native gives you genuine cross-platform deployment with a single codebase. Barcode scanning via the device camera works well using libraries like react-native-camera-kit. Offline storage is straightforward with SQLite (react-native-sqlite-storage). The ecosystem is mature — any problem you encounter has been solved by someone else, usually with a published library.

The downsides: JavaScript performance on low-end Android devices used in warehouses (underpowered, frequently dropped) is noticeably worse than native. The "bridge" between the JS thread and the native thread introduces latency for real-time scanning feedback. React Native apps also tend to be larger in file size than equivalent native apps, which matters when you are deploying over cellular to devices that rarely get WiFi.

Verdict: Solid choice for cross-platform warehouse apps with a competent JS team. Budget for performance testing on your actual device models, not the iPhone 16 in the developer's pocket.

Flutter

Best for: Teams willing to invest in Dart, or apps where animation/UI polish matters for usability.

Flutter compiles to native ARM code, which means significantly better performance on low-end devices compared to React Native. The widget-based UI model is well suited to warehouse interfaces where each screen has a clear, task-specific layout. Barcode scanning via flutter_barcode_scanner is reliable. Offline storage via Hive or SQLite is well supported.

The downsides: Dart is a niche language. If your development team knows JavaScript or C#, adding Dart to the stack increases hiring difficulty and reduces the pool of developers who can maintain the app long-term. Flutter's plugin ecosystem is smaller than React Native's, meaning you may need to write custom native code for edge cases (specialised Bluetooth scanners, thermal printers). Flutter apps on iOS are larger than React Native equivalents.

Verdict: Better technical choice for warehouse apps on paper. The language risk is real — consider it carefully if you plan to maintain the app in-house rather than through a retained agency.

Power Apps mobile (Model-driven / Canvas)

Best for: Organisations already deep in the Microsoft ecosystem, with simple warehouse workflows and existing Power Platform licensing.

Power Apps mobile runs within the Power Apps player app and connects directly to your ERP data sources via Microsoft Dataverse, Business Central connectors, or custom API connectors. It is quick to prototype — a basic scanning app can be up in a week. It handles authentication, offline mode, and device features (camera, GPS) through the Power Apps platform.

The downsides: Performance degrades quickly with complex warehouse workflows. Scanning barcodes via the Power Apps BarcodeScanner control introduces 2-4 seconds of latency on mid-range devices — unacceptable for high-throughput picking. Offline mode is limited to 200MB of data per device and synchronises via the Dataverse mechanism, which does not handle the conflict resolution patterns described above. Power Apps licensing costs for "premium" connectors (required for ERP API access) add up fast at scale: approximately +36 per user per month on top of your existing Microsoft licensing.

Verdict: Suitable for simple, low-volume warehouse apps (cycle counting, basic stock checks). Not appropriate for high-throughput picking, dispatch, or receiving workflows.

Quick comparison

Key workflows to digitise first

Do not try to digitise everything at once. The warehouses that succeed with mobile apps start with the workflows that cause the most pain and deliver the quickest return. Here is the order that works, based on the results we see in practice.

1. Receiving

Goods arrive. The receiving operative opens the app, scans the PO number from the delivery note, sees a list of expected items and quantities, scans each item as it comes off the lorry, and confirms receipt. The ERP updates stock quantities and sets the receipt status. No paper, no double-entry, no "we think it arrived but we are not sure" gaps.

2. Put-away

Once items are received, they need to go somewhere. The app presents the operative with a list of received items and suggested bin locations (based on item velocity, dimensions, and existing stock in the ERP). The operative scans the bin barcode to confirm placement. Stock location data in the ERP updates immediately.

3. Picking

Orders are released to the warehouse. The app assigns pick tasks to operatives, optimised for route efficiency (cluster pick, zone pick, or wave pick depending on your workflow). The operative scans the bin, scans the item, confirms the quantity, and moves on. When all items are picked, the app updates the order status in the ERP to "Picked" and moves it to the packing queue.

4. Packing

The packer scans the order ID (from a printed label or QR code on the picked items), sees a list of expected items, scans each item into the box, captures weight and dimensions if needed, and prints a shipping label via a Bluetooth or WiFi-connected thermal printer connected through the app. The app updates the ERP packing status.

5. Dispatch

The dispatcher scans each packed order as it goes onto the van. The app updates the ERP with the shipment tracking number, carrier details, and dispatch timestamp. If the order requires a signature (at the customer end during delivery), the app captures it and attaches it to the shipment record. No paperwork. No "did it actually go out?" uncertainty.

Real-world example: driver delivery app

One of the more revealing uses of a warehouse-connected mobile app comes not from inside the warehouse but from the delivery driver's cab. A UK wholesale distributor we worked with was running its own fleet of delivery vans. Drivers received paper manifests each morning with a list of stops, collected picked stock from the warehouse bay, and were unreachable until they returned or called in.

The problem: delivery confirmation was paper-based. Drivers collected signatures on paper delivery notes. If a signature was lost, the customer disputed delivery. If a driver encountered a problem (nobody at the address, damaged goods, customer refused part of the order), the process was to write a note, hope the office received it, and wait for instructions.

The mobile app replaced the paper manifest with a digital route list. Each driver's app showed their stops in sequence, with order details, delivery notes, and a signature capture screen. At each stop, the driver scanned the order barcode, captured a signature on the device screen, and optionally photographed the delivered goods (for high-value items). The app sent the POD data to the middleware, which attached it to the shipment record in the ERP and triggered an automated "delivered" notification to the customer.

The app handled exceptions. If the customer was not available, the driver marked the stop as "missed," added a note ("left card, will re-attempt"), and the app updated the ERP with the new delivery status. If goods were damaged, the driver photographed them, reported a short, and the app created a credit note request in the ERP automatically.

The results: lost PODs went to zero. Disputed deliveries dropped by approximately 85%. The average time from delivery to visible status in the ERP went from 24 hours (paper returned to depot, manually entered) to under 30 seconds. The same app architecture, incidentally, also handled internal stock transfers between the distributor's three warehouses — a problem that had previously required a dedicated administrator reconciling spreadsheets.

Common pitfalls and how to avoid them

We have seen enough warehouse mobile app projects go sideways to know the patterns. Here are the ones worth flagging before you start.

Underestimating device management. Warehouse devices get dropped, soaked in water, covered in dust, driven over by forklifts, and left on top of pallet racking overnight. Consumer-grade Android phones last three to six months. Ruggedised devices (Zebra TC5 series, Honeywell CK65) cost more upfront but last three to five years and include purpose-built scanning hardware that is faster and more reliable than camera-based scanning. Budget for the hardware. Your developers testing on a Pixel in a foam case is not the same environment.

Assuming the network works. Most UK warehouses have patchy WiFi at best. Concrete, steel racking, and roll-up doors create interference that enterprise WiFi surveys miss. Deploy a mesh network with access points every 15-20 metres in racking aisles. And assume the network will drop because it will — build the offline mode before you deploy, not after.

Forgetting about printer integration. Warehouse workflows require label printing (bin labels, shipment labels, pallet labels). If your app cannot trigger a thermal printer via Bluetooth or a print server, someone will end up manually writing labels. Plan printer integration as a first-class feature, not an afterthought.

Neglecting the middleware. The most common failure mode is building the mobile app beautifully and connecting it directly to the ERP API with minimal middleware. This works in development. In production, when twenty devices are scanning simultaneously during a receipt rush, the ERP API cannot keep up, requests time out, and the app shows errors to users who then work around it with paper. Build the middleware properly. The middleware is not optional.

Does the app replace any warehouse system?

No. A warehouse mobile app connected to your ERP does not replace your ERP, your warehouse management system (if you have one), or your existing processes. It is an interface layer that makes those systems accessible to people who do not sit at desks. The ERP remains the single source of truth. The warehouse management logic (if you use a WMS) continues to run. The mobile app is how your team interacts with that data during their physical tasks, rather than walking back to a terminal to type it in.

If you already have a WMS that provides mobile scanning, the question is whether its mobile interface is actually usable. Many WMS applications provide a mobile "companion" that is simply the desktop UI running in a browser on a small screen — the same problem as the ERP itself. If your existing mobile tool works for your team, you do not need a custom app. If your team is working around it with paper and spreadsheets, a purpose-built interface layer is almost certainly a better investment than replacing the WMS or ERP.

FAQ