/services/mobile-applications
Apps for the work that doesn't happen at a desk.
Field sales, warehouse scanning, delivery confirmation and stock counts — writing to the same Odoo records your office team works from, and built to survive a bad signal.
- Offline tolerated by design, not as a feature
- iOS + Android one codebase
- Odoo API one system of record
Facts. - Offline · tolerated by design, not as a feature - iOS + Android · one codebase - Odoo API · one system of record
/the-problem
Field data gets captured twice, and the second time is wrong.
A driver signs a paper docket. A rep writes an order in a notebook. A warehouse team counts on a clipboard. Then someone re-enters all of it, hours or days later, from handwriting, into the system everyone else is working from.
The cost isn't the typing. It's the lag — decisions made on a stock figure that's a day old — and the errors, which surface as reconciliation work at month-end and get attributed to "the system". Meanwhile the person best placed to catch a mistake, the one who was actually there, has moved on.
So we capture at the source, and we assume the network isn't there. An app that requires signal is a paper process with extra steps in the places where it matters most — a loading bay, a basement stockroom, a rural delivery round.
/how-theyre-built
How they're built
- Field sales — orders, customer visits, pricing, credit status
- Warehouse — barcode scanning for picks, receipts and stock counts
- Delivery — proof of delivery, signature capture, exception reporting
- Field service — job cards, time, parts consumed, photographs
- Approvals — the things that hold work up while somebody is travelling
- Offline queues that sync and resolve conflicts when signal returns
- One codebase, iOS and Android
- Odoo as the single system of record — never a parallel database
- Offline-first, with a defined conflict resolution rule
- Device features used where they earn it: camera, scanner, GPS, signature
- Published under your developer accounts, not ours
- Source in your repository, like every other custom build
/how-we-run-it
Six stages. Stage one is done standing up.
A single-workflow app runs eight to twelve weeks from discovery to store. Multi-workflow apps or anything with hardware integration take longer.
-
01
Field observation
We watch the work happen — in the van, on the floor. Descriptions of field work are reliably wrong.
2–3 days
-
02
Workflow design
The smallest screen sequence that captures what's needed. Every field defended or dropped.
1 week
-
03
Prototype
Clickable, on a real device, in the actual environment. Gloves and sunlight change opinions.
1–2 weeks
-
04
Build
iOS and Android from one codebase, against your Odoo instance.
4–6 weeks
-
05
Field testing
Real users, real routes, deliberately including places with no signal.
1–2 weeks
-
06
Store submission
Published under your accounts, with the review cycle handled.
1–2 weeks
/what-you-get
Four artefacts you keep.
Including the developer accounts — a mobile app published under a vendor's account is a hostage.
/where-this-fits
What comes before this, and what comes after.
A mobile app is only as good as the Odoo configuration behind it. Implementation and integration come first; support and customisation carry both afterwards.
/questions
Asked on every first call.
-
Often you should, and we'll say so. Odoo's app is capable and free, and for general access it's the right answer. Where it doesn't reach is a purpose-built workflow — a picking sequence with a scanner, a delivery flow with signature capture, a route that runs without signal. If the standard app covers it, that's the standard-first test applied here.
-
The app keeps working and queues what it captured. When signal returns it syncs, and where two people changed the same record it applies the conflict rule agreed before the build. Which rule is right depends on the workflow, so it's a decision you make rather than one the code makes.
-
You do — source in your repository, published under your Apple and Google accounts. An app published under a vendor's account is a hostage, and we won't do it that way even when it's easier.
-
Sometimes a little, for an endpoint or a status field. Often none — Odoo's API covers most of what an app needs. We'll scope both together so you see the whole cost rather than the app half of it.
-
Apps need it more than web systems do: OS releases, store policy changes, and Odoo version upgrades all force updates. It's covered under an AMC or a Success Pack, and it's worth budgeting for from the start rather than discovering at the first forced update.
/next
Show us where the paper is.
Thirty minutes, no slides. We will tell you straight if Odoo is not the answer.