Why I Designed the Forestry Traceability System to Work Offline

Most management software is designed assuming a stable internet connection. It's the default assumption in almost every tutorial, framework, or modern architecture. On a forestry concession in Congo or Cameroon, that assumption simply doesn't hold — and designing as if it did is the fastest way to build a system that never actually gets used in the field.

The context that forces a different approach

Felling crews often work hours away from any point of mobile coverage. Electricity, where it exists, isn't constant. A system that needs to "phone home" to function — to authenticate a user, save a record, validate a piece of data — stops working at the exact moment it's needed most: in the forest, with the freshly felled log right in front of you.

The architecture decisions that follow from this

• Local storage first. Each field device holds its own data fully and autonomously, without depending on a server confirming anything in real time.
• Deferred, non-blocking synchronization. Whenever a connection appears — at camp, on the road, on arrival at the sawmill — data is sent in the background, with no waiting or intervention required from the user.
• Conflict resolution planned in advance. If two devices capture related data before syncing, the system needs clear rules for what takes precedence, rather than simply overwriting or duplicating.
• Unique identifiers generated on-device, not by a central database, so a log has a valid, permanent ID from the second it's marked, without waiting for synchronization.

Why this isn't just "build a PWA and you're done"

There are plenty of generic "offline mode" solutions in modern web development, and most solve a much simpler case: an app that loses connection for a few minutes and gets it back right away. The real scenario here is different — days without connection, not minutes, with data that has to remain accurate and complete even if syncing takes weeks. That changes the underlying decisions, from the data model to how errors are communicated to the user right there on the field device.

What this means for a client evaluating the system

If your company is considering implementing (or migrating to) an EUDR traceability system, this is the technical question that actually matters to ask any vendor: what happens to the data if the device goes a week without a connection? The answer to that question says more about whether the system will actually work on your ground than any feature list.

Let's talk about your EUDR traceability