Field operations software where the company defines its own workflows
A Chilean field-operations company needed each type of job to follow its own sequence of steps, defined by them rather than by a developer. We built a platform where workflows are drawn as versioned graphs, routes are planned from a spreadsheet, and everything done on the road is logged.
Field operations — delivery and on-site services (Chile)
The brief
A delivery or on-site service job is not one process. A parcel drop, a scheduled installation and a returns pickup each have their own steps: who signs off before dispatch, what the driver has to capture at each stop, what counts as finished. Off-the-shelf field service tools assume one shape of job and let you tick a few options around the edges. This company needed the shape itself to be theirs.
More importantly, they needed to change it without calling a developer. Operations rules move — a client adds a verification step, a route type starts requiring a photo — and waiting on a release cycle for each of those is not workable.
On top of that: daily routes had to come out of a spreadsheet of destinations, split evenly across vehicles, with the dispatcher keeping the final say. Everything happening in the field had to leave a record — status, who changed what, with photographic evidence. And several companies had to run on the same platform, each seeing only its own data, with distinct roles inside: management, operations, crew leads, field operators.
No existing product did that combination with their circuits. The tool was designed from scratch for it.
How we built it
Workflows as a visual graph
Each order type is built as a graph of nodes in a visual editor. A node is a step in the circuit, with its own conditions for moving forward. The company models its own flow — which steps exist, in what order, what has to be true to advance — without touching code. Reusable forms plug into the nodes, so a capture form defined once can be used across several circuits.
Versioning so changes don't interrupt the day
Every graph is versioned and published. Orders already in progress keep running on the version they started with. This was the condition that made the editor genuinely usable: if editing a circuit could break the fifty orders currently out on the road, nobody would ever edit it mid-week. Published forms are snapshotted into the graph version, so a form change doesn't retroactively alter work already underway.
A dry-run runtime before publishing
Alongside the real runtime, there's one that executes a flow without persisting anything. You walk a new circuit end to end, see where it leads and where it blocks, and only then publish it. It turns workflow design into something an operations lead can test on their own.
From spreadsheet to routed day
Destinations come in as an .xlsx. Addresses are geocoded with a cache so the same address isn't paid for twice, duplicates are consolidated, then stops are clustered by proximity into even loads per vehicle, with the route optimised and drawn along real streets. The dispatcher can reorder stops by hand — and when they do, the system respects that order instead of re-optimising over it. The algorithm proposes; the person decides.
One codebase, web panel and driver app
The driver app ships to Android and iOS from the same codebase as the web panel. Drivers clock in and out on shifts, position is tracked through the working day, and operations watches a live monitor. Every edit to an order stores a structured diff: which field changed, the value before and after, photos included. Data is isolated per company across all queries, with differentiated roles and recurring subscription billing.
Results
Coverage across the order runtime, routing, geocoding, forms and the audit trail — the parts where a silent error would show up as a lost delivery.
New work circuits are configured from the panel, with no development work involved.
Changing a circuit doesn't interrupt the day: orders in progress finish on the version they started with.
Full traceability of what happens in the field — status, author, previous and new value, with photographic evidence.
In production and under active development since March 2026, built by a single full-stack developer.
Stack
- Django 5.2
- Django REST Framework
- GeoDjango + PostGIS
- PostgreSQL 16
- SvelteKit 2
- Svelte 5
- Tailwind CSS
- Capacitor (Android / iOS)
- Mapbox GL
- OSRM
- Docker