Why not just use the official Odoo mobile app?

If your users read data and occasionally enter something, use it. It is included and we will tell you so. It runs out of road on three specific things: heavy scanning, where going through the camera costs seconds per line that become hours per shift, genuinely offline work, and flows where you want three fields rather than the full back-office screen.

What happens when two people edit the same record offline?

There is no universal answer. For a stock pick, first sync wins and the second gets an explicit rejection. For a meter reading, both are kept. We decide that rule per record type during scoping, because discovering it in production means data quietly disappearing.

Do we need Apple and Google developer accounts?

Yes for anything published to a store, and they should be in your name. We can set them up and publish on your behalf, but a client who does not own their store accounts does not really own their apps. Internal enterprise distribution avoids the stores but needs its own programme.

What happens to the app when Odoo is upgraded?

A released app has to survive a server upgrade, because you cannot force two hundred handhelds to update the same morning. We put a versioned API between the app and Odoo rather than calling models directly, which gives a window where both versions work.

How long does a first app take?

Eight to ten weeks for a single-purpose app with offline sync, from scoping workshop to production. Later apps reuse the sync layer and run four to six weeks. A simple read-only dashboard can ship in three.

Mobile development

Mobile Apps Connected to Odoo

Field, warehouse and sales apps that write straight into your ERP. The hard part is not the interface, it is what happens when the network drops.

See the approaches

Odoo ships a general mobile app that surfaces the back-office screens. That works for a manager checking something. It works far less well for a warehouse operator scanning six hundred lines a shift, or a technician closing a job in a basement with no signal.

A mobile client against an ERP is a distributed-systems problem wearing a user-interface costume. Two people edit the same record offline, one syncs first, and something has to decide who wins. That decision, not the screen design, is what determines whether the app gets used or worked around.

If your current app authenticates over XML-RPC or JSON-RPC, it has an end date. See the RPC migration audit.

What we build

Purpose-built apps rather than a second ERP in a pocket. Each does a small number of things, and does them without a network.

Warehouse apps

Receiving, putaway, picking and counting on a scanner, with a local queue for when the Wi-Fi drops between racks.

Field service apps

Work orders, parts consumed, photos and customer signature, captured offline and synced when signal returns.

Sales apps

Catalogue, available stock, order capture and customer history in the field, without depending on the customer having Wi-Fi.

Inspection and quality

Readings, checklists and non-conformances recorded where they happen rather than copied up in the evening.

The sync layer

The part that actually matters: queueing, retry, conflict resolution, and a log of what was rejected and why.

Push and alerts

Push notifications on the Odoo events that need action, rather than an email nobody reads on a phone.

PWA or native?

The answer turns on one question: do you need the device hardware and genuine offline, or not.

Progressive web app

No app store, updates land instantly
One codebase across iOS and Android
Partial offline through the browser cache
Camera scanning, slower than a laser
No reliable push notifications on iOS

Cheaper, deployed instantly, no app store involved. Enough for most internal use cases.

Native app

Laser scanning and rugged handheld hardware
Genuine offline with a local database
Reliable push notifications on both platforms
NFC, background GPS and native camera access
Goes through the stores, with review delays

Necessary as soon as heavy scanning, real offline or push notifications enter the picture.

How a build runs

Durations for a first single-purpose app. Later ones reuse the sync layer and move faster.

Week 1

Use case scoping

Who uses the app, where, on what hardware and with what coverage. This is what decides progressive web app against native.

Weeks 2 to 3

Data model and conflicts

Which Odoo records the app reads and writes, and the rule that settles two competing offline edits.

Weeks 3 to 7

Build

Interface, sync layer and Odoo integration, delivered in testable increments on real hardware rather than a simulator.

Weeks 6 to 8

Field trial

A real crew, a full shift, in the areas where signal is worst. It is the only test that counts.

Weeks 8 to 10

Deployment

Store release or internal distribution, device management, and an update path that does not interrupt a shift.

Deployment and afterwards

Shipping the app is half the work. The other half is being able to update it without stopping your teams.

Store release or internal distribution

App Store and Google Play for customer-facing apps, enterprise distribution for internal tools that have no business in a public store.

Device management

Install, kiosk lockdown and remote update through your MDM, so two hundred handhelds do not get updated one at a time.

Versioning and compatibility

A released app in the field has to keep working against Odoo through the update window. We version the API accordingly.

Handover and source code

Repository, architecture documentation and release procedure handed to your team, so maintenance does not depend on us.

The source code is yours. The Apple and Google developer accounts stay in your name rather than ours, so changing supplier does not cost you your apps.

Backed by real migrations

Numbers like yours, validated on real migrations

These are three engagements where the projection actually turned into operational reality on Odoo, and the full case studies live on the migration service page.

ManufacturingV12 → V17
Industrial Manufacturer, Texas
12custom modules carried over, zero data lost
DistributionV14 → V18
Wholesale Distributor, Quebec
30%faster page loads once the upgrade shipped
Professional ServicesCE → Enterprise
Consulting Firm, Brussels
0hproduction downtime during cutover

Start with the use case

Thirty minutes on who would use the app, where, and with what signal. If a progressive web app is enough, we will say so rather than sell you native.

Book the call

Frequently asked questions

01
Why not just use the official Odoo mobile app?
If your users read data and occasionally enter something, use it. It is included and we will tell you so. It runs out of road on three specific things: heavy scanning, where going through the camera costs seconds per line that become hours per shift, genuinely offline work, and flows where you want three fields rather than the full back-office screen.
02
What happens when two people edit the same record offline?
There is no universal answer. For a stock pick, first sync wins and the second gets an explicit rejection. For a meter reading, both are kept. We decide that rule per record type during scoping, because discovering it in production means data quietly disappearing.
03
Do we need Apple and Google developer accounts?
Yes for anything published to a store, and they should be in your name. We can set them up and publish on your behalf, but a client who does not own their store accounts does not really own their apps. Internal enterprise distribution avoids the stores but needs its own programme.
04
What happens to the app when Odoo is upgraded?
A released app has to survive a server upgrade, because you cannot force two hundred handhelds to update the same morning. We put a versioned API between the app and Odoo rather than calling models directly, which gives a window where both versions work.
05
How long does a first app take?
Eight to ten weeks for a single-purpose app with offline sync, from scoping workshop to production. Later apps reuse the sync layer and run four to six weeks. A simple read-only dashboard can ship in three.