Professional work · mobile

Fieldbook

A field app for construction crews that keeps working where there's no signal.

Note: Name and branding changed
Stack: React Native · TypeScript · WatermelonDB · Redux Toolkit
Status: In production on iOS and Android

The problem

On a job site, connectivity comes and goes. Crews still need the latest plans, to-dos and forms, and still take photos and fill in reports in basements and on rooftops.

Every change they make has to reach the office eventually, in the right order, without being lost or applied twice.

What the app does

Everything works offlinePlans with annotations, to-dos, forms with QR scanning, daily reports, timesheets, work orders and photos, all usable with no connection.

Sync per moduleEach API domain pulls on its own and tracks its own last-pulled time per project, through one shared helper for batching, logging and permissions.

Changes as a queueEvery offline write is stored as an event and pushed in order. A built-in inspector lets users and support see, retry or clear anything stuck.

A codebase that scalesFeature modules with strict layers, generators that scaffold a feature, use case, component or screen, and two Jest setups for device and Node tests.

How it works

Each feature keeps business rules apart from storage and screens. Reads come from the local database, always; the network only ever feeds that database or drains the queue of local changes.

Inside a feature module

Screens & hookspresentation

Reactive queries via RxJS
Resolve dependencies

calls

Use casesdomain

Business rules only
No framework imports

interface

Repositoriesdata · tsyringe

Implement domain interfaces

read / write

WatermelonDBSQLite

The source of truth on the device

Sync

Offline event queuelocal writes

Ordered intents
Retry or heal from the inspector

push every 10 s when online

APIREST

Applies changes
Returns active IDs per module

pull, Wi-Fi-only if set

Pull per modulebatch write

Create and update in one batch
Delete what the server no longer lists

Key decisions

Strict layers, enforced by the linterEach feature has domain, data and presentation layers, and ESLint blocks any import past its public barrel. The rule holds even under deadline pressure.
The server lists what exists; the device deletes the restEach pull returns every active ID, and the client removes local rows that are missing. No tombstones or deletion log needed on the server.
Writes are eventsOffline changes are stored as ordered intents, not as edited rows waiting to be diffed. That makes them visible, retryable and easy to reason about.
Dependency injection for fast testsUse cases and repositories are registered with tsyringe, so business rules run in plain Node tests without a device or simulator.
Respect the user's data planA Wi-Fi-only setting is checked before any module syncs, along with connectivity and session guards.

Where it stands

Today

In production on the App Store and Google Play, released through code review, preprod and QA on deployed builds.

About this case study

The product name, company, identifiers and endpoints have been changed. An anonymized code sample is available on request.

React NativeTypeScriptWatermelonDBSQLiteRedux ToolkitRxJStsyringeJestDetoxMaestroSentryDatadogi18n FR/EN