The work happens in the field. The system still assumes a desk.
What does mobile-first operations actually mean?
Mobile-first operations means the field is the primary workplace, not a consumer of desk reports. Enablement starts by naming which captures, approvals, and handoffs must happen on a phone, what truth lives in the ERP, and how conflicts reconcile when connectivity fails. It is not “build an app” by another name.
Most mobile conversations arrive as a build pitch: screens, store listings, a framework choice. The hard part sits earlier. The DSA, painter, or warehouse lead already works around the ERP with WhatsApp, paper, and a spreadsheet that finance does not trust. An app that does not write back cleanly becomes a second system. An app that requires perfect connectivity fails on the route that matters.
We treat mobile-first as a diagnosis with honest exits: a native field surface via Mobile App Development, a web or custom surface when that fits better, integration engineering when the estate already has tools that will not talk, or no new surface until the desk process is honest. Selling the app before the diagnosis is how field teams get a pretty client that nobody opens after week three.
Does any of this sound familiar?
Field staff finish the day on paper or chat; someone re-keys into the ERP after hours.
Leadership wants “a mobile app” but cannot name which field decision it would change next month.
Inventory, visits, or redemptions disagree between the phone, the warehouse, and finance.
A previous app shipped without offline behaviour; it dies exactly where coverage is weakest.
Approvals still require a laptop login that field managers do not have on the road.
Quotes compare frameworks and screen counts, not write-back, conflict rules, or who owns exceptions.
If you recognised three of these, you do not need a prettier UI. You need a decision that the field and the ledger can both survive.
What mobile-first looked like when it had to hold.
Endurance · distribution in the field
A DSA-facing surface on top of the Odoo system behind a growing field force. Enablement meant deciding what the phone owns (visits, submissions, day-to-day capture) and what the system of record keeps authoritative. Delivery sits on Mobile App Development; the decision work came first.
Read the Endurance case study →Cemseal · field loyalty and payout
MAAN, a field-loyalty app on a manufacturing Odoo estate: capture in the field, ledger in the system, redemption through banking integration. Mobile-first here meant the painter’s phone is the workplace; the ERP still owns money movement and audit.
Read the Cemseal case study →What a mobile-first engagement decides, and what it does not.
In the decision
- Which field judgements and captures must live on the phone.
- What remains authoritative in the ERP (stock, money, compliance).
- Offline, conflict, and exception rules before any screen is designed.
- A written recommendation: native app, lighter surface, integration-first, or no new client.
- Clear fences so delivery quotes are not reopening the strategy fight mid-build.
Not in the decision
One team for the phone and the system behind it.
We build field surfaces in-house (Flutter and React Native / Expo) when a native app is the right call. The same practice runs the Odoo systems those apps write into. That is the point of mobile-first as a Solution: the phone is not a side project; it is how the operation moves, and the ledger has to agree.
We will not sell an app that becomes a second system of record. If the hard part is sync, we say so and route to Integration. If the hard part is a broken live estate, we route to Rescue.
How we work is on How we work. Engagement shapes are on Engagement models.
How a mobile-first read runs.
-
01
Situation call
Where the field works today, what gets re-keyed, what breaks offline, and whether an app is already live and untrusted. If production field software is already failing users, we route to Rescue first.
-
02
Field and ledger map
Name the captures, approvals, and handoffs. Mark what must sync, what can wait, and who owns conflicts.
-
03
Options on paper
Native app, lighter surface, integration-first, process-only, or do not build. Each option carries what the field gives up and what finance still needs.
-
04
Recommended path
One primary recommendation and the conditions under which we would change it. Delivery is scoped only after this lands.
-
05
Hand-off into Services or stop
You keep the write-up. If you stay with us, the next page is Mobile App Development, Integration, or Rescue, not a vague “phase two screens.”
Questions we get first.
Is this the same as Mobile App Development?
No. Mobile App Development is the delivery of Flutter and React Native apps in-house. This page is the decision work that says whether that delivery (or a lighter surface, or no new client) is the right first step. When the path is a native build, we send you to Mobile App Development.
Do your field apps connect to Odoo?
When the client runs Odoo with us, yes: the phone is a surface on live operations, not a separate product database. We claim that connection only where it exists.
We already have an app nobody uses. Start here?
If it is live and failing trust or sync, start at Rescue & Stabilization. Mobile-first strategy on top of a broken client is how you fund a rewrite without fixing ownership.
Will you always recommend a native app?
No. Sometimes a process change, a web surface, or fixing the integration layer is the honest answer. We will say that instead of selling the more expensive build.
What about offline?
Offline behaviour is part of the decision, not a polish pass. If the route that matters has no coverage, “online-only” is a failed design.
What does this cost?
A fixed-scope read after the situation call, priced in writing before work starts. Delivery projects are separate quotes after the recommendation.
Get a clear path before the next app pitch.
Tell us what the field re-keys today. We will say native app, lighter surface, integration-first, or do not build, and which Service page (if any) comes next.