Hi everyone,
This is my first post here in quite some time, and it will be a long one. I wanted to share an experience that, for me, really changed how I look at what can be built with Frappe.
This isn’t meant to be a promotional post, it’s more about sharing what we found possible to build with Frappe when working under real-world constraints like offline usage and field operations.
We started working on a field-service and delivery workflow where the environment was very different from what ERP systems usually assume. The users weren’t sitting in an office with stable internet, they were on the road, often in areas where connectivity drops completely.
At the same time, their entire day, tasks, customer context, billing, and even photos, needed to be handled as they worked.
At first, we tried thinking in terms of standard ERP flows: multiple forms, server-side actions, step-by-step processes. It quickly became clear that this approach wouldn’t work in the field. The friction was too high, and once the internet dropped, everything stopped.
So we shifted the approach completely.
Instead of asking how the workflow could fit into the system, we started asking how the system could adapt to the workflow.
That decision changed everything.
What made this interesting wasn’t just solving these problems, but doing it within Frappe, while still relying on its core concepts (DocTypes, permissions, backend logic, etc.).
What the workflow looks like
We built a custom Desk page that acts as a daily operational workspace, essentially a single interface where everything happens:
- Start Day → select site, route, truck
- Tasks → full customer + delivery context
- Billing → created directly from task flow
- Offline → continue working without interruption
- Sync → automatic when connection returns
- Photos → captured and tied to tasks
- End Day → summary + session closure
Everything happens in one place.
Where things got interesting
The bigger challenge wasn’t the interface, it was what happens when the internet disappears.
One interesting part of this project is how the offline aspect came into it.
The push to build this as an offline-capable system actually came from Bernard.
The question was pretty straightforward:
If the work is happening in the field, why should everything stop just because the connection drops?
That shifted how we approached the entire system.
Instead of assuming the server is always available, we had to start thinking about what happens when it isn’t and how the workflow should continue regardless.
What broke (and what we learned)
We had to rethink the system to behave as if the server might not exist for long periods of time.That meant allowing tasks, invoices, and photos to be stored locally, queued, and synced later. But once you go down that path, things get complicated very quickly.
We started running into questions that don’t really show up in typical ERP development:
- What happens if a task syncs but the invoice doesn’t?
- How do you prevent duplicate submissions?
- When should the system block the user vs let them continue?
Tax complexity
Another unexpected area of complexity was tax handling.
In our case, taxes weren’t just static configuration. They depended on:
- province
- customer(native don’t pay)
- and additional rules like carbon tax
Getting this right while offline and ensuring it still aligns with ERPNext after sync, turned out to be more challenging than expected.
Local storage trade-offs
Once business data exists in the browser, you have to think about security differently.
We ended up adding:
- encryption
- inactivity-based locking
But even then, it’s always a balance between usability and safety.
Large Desk page Challenges
Maintaining a large custom Desk page also brought its own issues:
- managing state across tasks, billing, and media
- avoiding unnecessary refreshes
- keeping the UI stable and responsive
Small UI issues that don’t matter in office setups become very noticeable in the field.
Why we didn’t go with a native mobile app
One question we considered early was whether to build this as a native Android app instead.
While that would have simplified some offline aspects, it would have introduced a different kind of complexity, especially around maintaining business logic in multiple places.
In our case, things like:
- tax calculation (including province + carbon tax)
- billing logic
- workflow rules
are tightly integrated with ERPNext.
Re-implementing those in a mobile app would mean duplication and long-term maintenance overhead.
By staying within Frappe, we were able to keep a single source of truth for business logic, while building offline behavior on top of it.
It made the frontend more challenging, but the overall system easier to maintain.
Closing thought
Through all of this, what stood out to me wasn’t just the solution we ended up with, but the fact that Frappe didn’t get in the way.
Even when we moved far from standard multi-form workflows into something closer to a single-page, offline-capable system, we were still able to rely on its core building blocks.
It felt less like customizing a system, and more like using a framework to build something shaped around real operational constraints.
I’d be really interested to hear how others have approached similar problems — especially around offline workflows, sync strategies, or large custom Desk experiences.
Curious to hear your thoughts.
Thanks for taking the time to read through this.
I’m Sahil, and this has been our experience building with Frappe.
If helpful, I’ve included a short demo video showing the workflow: https://www.youtube.com/watch?v=cZlY_xtcua4