Mobile Apps on ERPNext: Give Your Field Team a Real Tool
Karani Geoffrey6 min readYour ERP is excellent at recording what happened. The problem is that in most Kenyan businesses, the things that happen happen outside the office - a delivery signed at a customer's gate in Nakuru, a technician repairing a generator in Athi River, a sales rep taking an order in a duka in Kisii, a guard checking in at 4am at a site in Mombasa.
Between the event and the record sits a gap. The gap is filled by a delivery book, a WhatsApp photo, a phone call and someone in the office typing it all in tomorrow. Every hour of that gap is stock you cannot see, cash you cannot chase and a customer question you cannot answer.
A mobile app built on top of ERPNext closes the gap. This article covers what those apps actually do, how they connect, why offline-first matters more than anything else in Kenya, and how to scope one.
What a field app on ERPNext actually does
The point is not to put the whole ERP on a phone. Nobody wants a general ledger on a five-inch screen. The point is to give one role the three or four things they need, done in seconds, with one hand, in poor light and worse network.
Sales and van sales
- Take an order against the live price list, with the customer's own discount structure applied
- See available stock by warehouse before promising a delivery
- See the customer's outstanding balance and ageing before extending more credit
- Capture payment, including M-Pesa, and issue a receipt on the spot
- Record a visit with GPS and photos, so route coverage is real rather than reported
Delivery and dispatch
- Today's delivery notes on the driver's phone, in route order
- Proof of delivery: signature, photo, timestamp, GPS coordinates
- Short delivery and rejection capture at the point it happens, not three days later
- Cash and M-Pesa collection reconciled per trip
Field service and maintenance
- Assigned jobs with customer history and equipment records
- Checklists, meter readings and fault codes
- Parts consumed, issued straight from the technician's van as a stock warehouse
- Time on site, before and after photos, customer sign-off
Stock and warehouse
- Barcode scanning for receipts, transfers and picking
- Stock counts done on the shelf rather than on a clipboard then re-keyed
- Bin-level lookups so nobody walks the warehouse to answer a phone question
Approvals for managers
- Purchase orders, credit limit overrides, leave and expenses approved from a phone
- Push notifications so approvals stop being the bottleneck they usually are
Offline-first is not optional in Kenya
This is the single most important design decision, and the one most often skipped. Coverage in Kenya is good in towns and unreliable everywhere else. A basement warehouse, a rural route, a construction site, a lift in a Nairobi office block - all produce the same result: a spinning loader and a frustrated user who goes back to paper.
An offline-first app treats the network as an optimisation, not a requirement. That means:
- A local database on the device holding the data that role needs - their customers, their price list, their stock snapshot, their open jobs
- Writes queue locally and sync when connectivity returns, in order, with retries
- Client-generated identifiers so the same record is never submitted twice after a partial sync
- Explicit conflict rules - what happens when the price changed on the server while the rep was offline, or two people counted the same bin
- Visible sync state, so the user knows what has reached the office and what has not. Ambiguity here destroys trust faster than any bug.
An app that works perfectly on office wifi and fails on a rural route has not been built for the job. Test on the worst network your users face, not the best.
How the app connects to ERPNext
ERPNext, built on the Frappe framework, is a genuinely good mobile backend. It already has authentication, roles and permissions, a REST API over every DocType, webhooks, background jobs and a full audit trail. You are not rebuilding a backend - you are exposing a narrow, deliberate slice of one.
The pattern we use is purpose-built endpoints in a custom app rather than generic CRUD calls from the device. A single endpoint that returns everything a rep needs for the day beats fifteen round trips over a weak connection.
import frappe
@frappe.whitelist()
def sync_bundle(last_sync=None):
user = frappe.session.user
territory = frappe.db.get_value("Sales Person", {"user_id": user}, "territory")
return {
"server_time": frappe.utils.now(),
"customers": frappe.get_all(
"Customer",
filters={"territory": territory, "modified": [">", last_sync or "2000-01-01"]},
fields=["name", "customer_name", "credit_limit", "mobile_no"],
limit_page_length=0,
),
"prices": frappe.get_all(
"Item Price",
filters={"selling": 1, "modified": [">", last_sync or "2000-01-01"]},
fields=["item_code", "price_list", "price_list_rate"],
limit_page_length=0,
),
}
Note the delta sync on modified timestamp. Downloading the full master list on every open burns bundles and battery, and on a slow connection it means the app is unusable exactly when it is needed.
Which framework
| Approach | Good for | Trade-off |
| React Native | Teams already working in TypeScript and React, shared logic with a web portal | Native modules occasionally needed for scanning or printing |
| Flutter | Highly custom interfaces, consistent behaviour across devices, strong offline tooling | Dart is a separate skill set from your web stack |
| Progressive web app | Fast to ship, no store approval, easy updates | Weaker offline and hardware access, poorer fit for scanning and background sync |
We build with React Native and Flutter, and we choose based on the hardware the app must talk to and the team that will maintain it. For barcode scanning, thermal printing, background location and heavy offline use, native beats a web wrapper every time.
What it costs to get field apps wrong
- Online-only design. Adoption collapses on the first bad-network day and never recovers.
- Porting the desktop UI. Twenty fields on a phone screen means the rep fills three and guesses the rest.
- No duplicate protection. Retry logic without client-side identifiers creates double orders and double stock movements.
- Ignoring device reality. Field staff have mid-range Android phones, cracked screens and limited bundles - not the test device on your desk.
- No adoption plan. If the paper book still works, people will use the paper book. Retire it deliberately.
- Bypassing ERPNext permissions. Any endpoint that ignores role rules is a data leak waiting for a lost phone.
How to start
- Pick one role and one workflow. Proof of delivery, or order capture, or stock count. Not all three.
- Watch that role work for a day. The real process is never the documented process.
- Define the offline scenario explicitly. What must work with no signal for four hours?
- Fix ERPNext first. If your price lists, warehouses and item master are messy, the app will simply broadcast the mess to the field.
- Pilot with your most sceptical user. If the toughest driver adopts it, the rest will follow.
And if someone is proposing an AI assistant for your field team before the basic capture works, be sceptical. Capture reliable data first, then make it clever. We wrote about that ordering in don't get pressured into buying AI before your business is ready.
Let us build the tool your field team will actually use
Upeosoft Limited is a Nairobi-based ERPNext consultancy extended with custom engineering. We build mobile and field applications in React Native and Flutter on top of Frappe and ERPNext, with offline-first sync, M-Pesa collection and integration into the systems you already run. Over 200 systems delivered, across retail and distribution, automotive, real estate, waste management, security services, manufacturing, professional services and lending.
If your field operation still runs on delivery books and WhatsApp photos, tell us what a typical day looks like and we will show you what it could look like instead.
- Email: consult@upeosoft.com
- Phone: 0116 888 777
- Web: upeosoft.com