Extending Odoo with a Custom Mobile App: Field Sales, Delivery and Customer Apps

Odoo's mobile app mirrors the web interface: every model, every menu, every field. That is exactly right for a manager approving expenses on the way to a meeting, and exactly wrong for a delivery driver with sixty stops, a merchandiser visiting twenty supermarkets, or a customer who wants to reorder last month's basket in three taps. Those users need a purpose-built app with five screens, not five hundred.

We build these apps for companies running Odoo in the GCC and Egypt. This is how the architecture works, the decisions that keep the ERP healthy, and the three app types that pay for themselves fastest.

Why not just use Odoo's app?

• Too much. The standard app exposes the whole system; field users need a fraction of it and get lost.
• Online-first. Warehouses, basements and desert roads have bad connectivity. Field apps must work offline and sync later.
• Wrong interactions. Barcode scanning, signature capture, photo proof, maps and turn-by-turn navigation need native device access and careful UX.
• Customers cannot use it. Odoo's portal is a web page; customers expect an app with push notifications and saved payment methods.

The architecture that works

The mistake is letting the app talk to Odoo models directly. It couples the app to the ERP's data model, leaks business rules into the client, and makes every Odoo upgrade an app release.

Instead:

1. A thin API module inside Odoo. A custom module exposes a small set of purpose-built endpoints — "today's route", "confirm delivery", "reorder" — built with Odoo controllers or the JSON-RPC layer. Business rules stay in Odoo where they belong. See custom Odoo module development for the module structure.
2. Authentication built for devices. Per-user API keys or OAuth tokens, scoped to what the app can do, with device registration for push notifications. Never the user's Odoo password stored on a phone.
3. Offline-first on the phone. The app keeps a local database (SQLite or Drift in Flutter) and a sync queue. Actions are recorded locally with timestamps and pushed when online; conflicts resolve by rule, not by prayer. Our guide to offline-first Flutter apps covers the patterns.
4. Queued work on the server. Anything slow — generating a ZATCA invoice, booking a courier, sending an SMS — runs as a queued job so the app's request returns immediately.
5. One codebase for iOS and Android. We use Flutter, which delivers native performance and a single team; the trade-offs are in our Flutter vs React Native comparison.

Three apps that pay back quickly

Delivery and driver app

Route for the day, stop details, navigation hand-off, proof of delivery (photo, signature, OTP), cash and card collection, returns, and a status feed back into Odoo's delivery orders. Payback comes from fewer failed deliveries, faster cash reconciliation and real-time visibility for dispatch. Typical build: eight to twelve weeks. Companies running their own fleets in the GCC — see building driver and logistics apps — get the most from it.

Field sales and van sales app

Customer list with credit limits and visit plans, product catalogue with live stock and price lists, order and invoice on the spot (ZATCA-compliant in Saudi Arabia), payment collection, and merchandising photos. Reps stop calling the office to check stock, and orders arrive in Odoo before the rep leaves the shop.

Customer app

Catalogue, reorder, order tracking, invoices and statements, support tickets, loyalty. For B2B distributors, a customer app that reads price lists and credit terms from Odoo replaces a WhatsApp order desk. For consumer brands, it becomes the loyalty channel. Retention mechanics matter here — see app retention strategies.

What it costs and how long it takes

A focused field app on top of an existing Odoo system is a smaller project than most companies expect: the data model, users and business rules already exist. Typical ranges in the GCC are $15,000 to $45,000 for a single-role app (driver, rep or customer) delivered in eight to fourteen weeks, plus the Odoo-side API module. Our general mobile app cost guide explains the drivers; the Odoo integration usually reduces them because the backend is already there.

The checklist before you start

• Is the Odoo data clean enough to expose? Customer addresses with coordinates, products with images, price lists without duplicates.
• Which version of Odoo, and is it current? Building on an unsupported version compounds the debt — see the upgrade guide.
• Who owns the API module? It should live in your Odoo repository with tests, like any other module.
• What happens offline? Write the list of actions that must work without a signal.

Key takeaways

• Purpose-built field and customer apps beat the generic Odoo app for drivers, reps and customers.
• Put a thin API module inside Odoo; keep business rules on the server; never let the app touch models directly.
• Offline-first with a sync queue is mandatory for field work in the region.
• Driver, field-sales and customer apps are the three with the fastest payback, typically $15,000 to $45,000 each.

SummationWorks builds Flutter apps on top of Odoo for distributors, retailers and service companies in the GCC and Egypt. See our mobile app services and Odoo and ERP services, browse our work, or talk to us about the app your field team needs.