Technology Services · Mobile Applications
Mobile app development for field, warehouse and sales teams.
Sales, warehouse, counting and label apps that work online and offline and synchronize with SAP Business One® and other business systems.
- NET
- No signal, and nobody knows when it returns
- TCH
- Hands gloved, cold, or holding something else
- PWR
- A ten-hour shift and the charger in the van
- SYN
- Two people changed the same thing while one was offline
Requirements
Six conditions that decide the architecture
Every one of these breaks an assumption that office software is allowed to make. They are settled during scoping, not discovered during a pilot.
Operating conditions
Requirements, not features
NET
There is no signal, and nobody knows when it will come back
What it breaks
Anything that calls a server to validate, price or save. The screen spins, the driver waits, the stop takes four minutes instead of one.
What we build instead
The device holds its own copy of the catalog, the customer's prices and their open balance. Work is written locally first and queued for sync.
TCH
The hands are gloved, cold or holding something else
What it breaks
Small targets, long forms, anything needing two hands or precision. Accuracy collapses and people start guessing.
What we build instead
Large targets, one-handed reach, and a hardware scanner wherever a number is being read off a label. Typing a lot number is a data-quality decision.
LGT
Direct sun on a loading dock, or a dim aisle at 5am
What it breaks
Low-contrast interfaces, thin type, and colour used as the only signal. Neither extreme is where the design was reviewed.
What we build instead
High contrast as the default rather than a setting, weight and shape carrying status alongside colour, and text sized for arm's length.
PWR
The shift is ten hours and the charger is in the van
What it breaks
Constant polling, background location, chatty sync. A device at 8% at 2pm is a device that stops being used.
What we build instead
Sync on change and on a schedule rather than continuously, batched uploads, and no background work that the job does not require.
SYN
Two people changed the same thing while one was offline
What it breaks
Last-write-wins, which silently discards somebody's work and is discovered at month end.
What we build instead
Conflicts are detected and surfaced, never resolved by accident. Orders and counts carry their own identity so a retry cannot duplicate them.
DEV
The device is shared, lost, or leaves with the employee
What it breaks
Local data with no boundary around it, and accounts that outlive the person who used them.
What we build instead
Sign-in per person on shared hardware, local data scoped to the session, and access that can be revoked centrally the same day.
The question everyone asks
Native or cross-platform?
There is no house answer, and a firm that gives you one in the first meeting is telling you about their staffing, not about your project. Six inputs decide it, usually in this order.
- 01
Scanning hardware
A device with a physical scan engine usually ships a vendor software kit, and how well that kit is supported outside native code decides the question before anything else does.
Often native
- 02
Label and receipt printing
Printer manufacturers publish native libraries first. Bridging them is possible and adds a layer that has to be maintained through every printer firmware change.
Often native
- 03
The fleet you already own
One rugged Android platform is a different problem from reps on their own phones across two operating systems. Nobody replaces a fleet to suit a build choice.
Either
- 04
How much of it is forms
Order entry, counts and proof of delivery are mostly lists, forms and a local database. That is exactly where cross-platform is strongest.
Often cross-platform
- 05
Who maintains it in year three
One codebase and one skill set is a real operational advantage, and it is worth paying for unless the hardware genuinely forbids it.
Often cross-platform
- 06
Budget, stated honestly
Two native applications cost close to twice one. Where the requirement does not demand it, spending that on the second release is the better trade.
Often cross-platform
We answer this in writing during scoping, with the reasoning, so the decision can be argued with rather than accepted.
Scope
What we build
- 01
Field sales applications
Customer data, pricing, stock and order entry for reps on the road.
- 02
Warehouse and inventory applications
Receiving, put-away, picking, transfers and counts on handheld devices.
- 03
Barcode scanning
Camera and dedicated scanner support for items, bins, batches and labels.
- 04
Offline-first synchronization
Local storage with conflict-aware sync, because warehouses and routes do not have reliable connectivity.
- 05
Label and document printing
Print from the device to wireless label and receipt printers.
- 06
Integration with SAP Business One
Documents created on the device become SAP Business One documents with your rules applied.
Not theoretical
Three of these are already products
Which is usually the faster route. A configured product that covers 90 percent of the requirement beats a bespoke build of the same thing, and we will say so.
- 01Sales Rep AppOrder entry, customer data and pricing on the route, with no signal assumed.See it
- 02Inventory CountingBarcode-driven physical and cycle counts, reconciled back to SAP Business One.See it
- 03Price Label PrintingLabels generated from live SAP Business One item and price data, printed at the shelf.See it
What it syncs with
The rest of the system
- CoreSAP Business OneThe system of record everything else reads from and writes to.Overview
- Layer 01B2B eCommerceCustomers who order themselvesA portal with their pricing, live stock and account history. Orders arrive as SAP Business One sales documents.See it
- Layer 02Sales Rep AppCustomers who need a visitReps carry pricing and stock on the route, work with no signal, and sync orders when they reconnect.See it
- Layer 03Inventory CountingMaking the stock figure trueBarcode counts and cycle counts, with variances reviewed before anything posts to the ledger.See it
- Layer 04Price Label PrintingThe shelf edgeLabels generated from the same item and price data, so what is on the shelf matches the invoice.See it
Questions
About mobile work
Next step
Describe the problem. We will tell you what it takes to solve it.
Send a few lines about the process or system you are dealing with. We come back with questions, options and a realistic sense of effort.