Case Study · Design & Development
An offline-first harvest tally book for orchard crews. Track who picked what in the field with no signal, keep an auditable record of every count and pay rule, and sync when the phone finds a network.
Orchard harvest still runs on paper. A crew boss walks the rows with a clipboard, tallying who picked how many bins, in blocks with no cell signal. Later, someone reconciles it by hand into pay: piece rates, who is owed what, which counts were disputed. It is slow and error-prone. When a picker's pay depends on a number scribbled hours ago, disputes are common and there is no record to settle them.
Orchardly moves the tally book onto a phone that works offline in the field, keeps an auditable trail of every count and pay rule, and syncs when it gets a network.
Orchardly is a mobile app for the producer side of harvest: crews, tallies, pay, and packing-house handoff. It runs fully on-device. A crew boss opens the app in an orchard with no signal, records the day's tallies, and the data lives in a local SQLite database until the phone finds a network and syncs.
The current build is a Phase 1 working demo, driven by pilot-shaped data (real tally sheets, real pay rules, five demo personas), with the crew-boss workflow wired end to end: roster, day tallies, and a pay week that computes owed, paid, and unpaid. It is built for the field first. Everything the crew boss needs works without a connection, and sync is a background convenience rather than a requirement.
How it's built
The visible product is a tally book. The engineering is offline-correct data and an audit trail solid enough to settle a pay dispute.
The app runs on a local SQLite store on the phone, with a full migration chain defining the schema on-device. A crew boss in a dead zone gets the whole workflow: roster, tallies, and pay, with no network at all. When the phone reconnects, local operations batch up and push to the Rails backend. Offline here is the default, and connectivity is the exception.
Piece-rate pay is only as trustworthy as the tally behind it. Every tally write is logged atomically to an append-only edit log, and pay rules are append-only too: when a rule changes, the old one is superseded rather than overwritten, and each tally snapshots the exact pay rule it was written under. Owed and paid are derived from that record, never denormalized onto the tally. A count, and the pay that follows from it, can always be traced back to what was actually recorded.
The code is organized by role (crew boss, picker, and producer) instead of by screen, with per-persona capability gating deciding what each user can see and do. That split lets the workflows grow independently and, if it ever makes sense, separate into their own apps without a rewrite. The domain model underneath is real: people and their connections (who picks for whom), crops and varieties and units, and pay rules and payouts with a custody chain.
Orchardly is the producer-operations client of the Growoperative and FOAF ecosystem: shared identity, supply-chain events, and mutual-credit settlement. It is designed to connect into that network but to run on its own without it. A harvest crew can use it as a standalone tally book today, and the same records feed settlement and handoff when the rest of the network is in play.
The Phase 1 build is a working app on real infrastructure: Expo and React Native on the phone with a Rails API behind it, seeded from a pilot CSV pipeline that shapes the demo data like an actual season. You can open it in a simulator, switch between five crew personas, edit a day's tallies, and watch the pay week recompute.
On-device SQLite · full migration chain · append-only tally + pay-rule ledger · batched sync to a Rails API · role-based architecture · pilot CSV seed pipeline.
What this shows
The visible product is a phone app a crew boss taps through in an orchard. The harder part is underneath: data that has to be correct with no connection, an audit trail solid enough to settle a pay dispute, and a schema that fits into a larger network without depending on it.
This is the kind of work Novadiem takes on: real operations software for people doing physical work in places software usually ignores, designed and built from the field up. It is a Phase 1 demo today, and the foundation under it is the real product.
Offline-first mobile apps, auditable data, and the backends they sync to, designed and built from one practice.
