Skip to content
All projects

Flagship system

Construction ERP

Offline-First · Desktop · Synchronisation

An enterprise resource planning system for construction, delivered as a native Windows desktop application that runs fully offline — all records persist locally and synchronise to other authorised installations when connectivity returns.

6
Technologies
2
Domains
6
Capabilities
1
Public links

Who it's for

Construction companies whose site and field staff work where connectivity is unreliable or absent — and who don't want to pay for an always-on server.

Where it fits

On-site Windows laptops and office desktops that must stay fully productive offline and converge automatically when a connection returns.

The hard part

The problem

Construction work happens on sites with unreliable or absent connectivity. A hosted web ERP is useless the moment the network drops — yet field and site users still need full access to project, resource and procurement data.

Key constraints

The application had to work with no network at all, with no always-on central server to host, pay for, or fail. When connectivity returned, distributed copies had to converge — including resolving edits multiple users made offline to the same records.

Architecture overview

A Tauri application (Rust shell + web frontend) writes all records to local device storage, so the app is fully functional offline. Internal REST contracts decouple the interface from the data layer, so the same API surface serves both local operation and synchronised multi-user operation. On reconnection, changes propagate peer-to-peer to other authorised installations, with conflict reconciliation for divergent offline state.

Two devices · no central server

Device A

Local write
On-device store

offline · fully productive

Device B

Local write
On-device store

offline · fully productive

Peer sync
Conflict reconciliation
peer-to-peer
Two devices work independently offline, each writing to local storage. When connectivity returns, their changes propagate peer-to-peer across a sync bridge and a conflict-reconciliation step converges divergent edits — with no central server between them.

How it works

What's actually in it.

  1. 01Local-first data persistence: complete functionality with no network access.
  2. 02Peer synchronisation on reconnection keeps distributed copies consistent without a hosted backend.
  3. 03Native desktop packaging with Tauri — a Rust shell + web frontend, far lighter than an Electron equivalent.
  4. 04Internal REST contracts decouple interface from data so one API serves local and synced operation.
  5. 05Modular ERP domains (project, resource, procurement, reporting) over a shared permissions model.
  6. 06Conflict reconciliation for concurrent offline edits, resolving divergent local state on sync.

Engineering decisions

Local-first with peer sync instead of a hosted server

The default assumption for an ERP is a central server everyone connects to. Here the network is treated as an optimisation, not a requirement: each installation is complete on its own and syncs peer-to-peer when it can. That removes the always-on hosting cost and the single point of failure entirely.

The trade-off

Peer synchronisation and conflict reconciliation are genuinely harder than a single authoritative database. The reward is an application where the network can disappear and every user stays fully productive.

The obvious approach

Host the ERP as a web service with a central database everyone connects to.

Why I didn't choose it

On a construction site with no connectivity, a hosted web app simply stops working — and it adds a permanent server to host and a single point of failure.

My approach

Make each desktop installation locally complete with on-device storage, and synchronise peer-to-peer on reconnection with explicit conflict reconciliation.

Trade-offs

You take on distributed-systems complexity (sync, conflicts) to remove the hosting dependency and keep the app working with zero connectivity.

Technical highlights

  • No hosted server — no hosting cost, no single point of failure.
  • Rust/Tauri binary with a substantially smaller footprint than Electron.
  • Same REST surface serves both offline and synced multi-user modes.

Claims & evidence

  • The application operates fully offline with all records on local device storage, requiring no hosted central server.

    Qualitative · Construction ERP architecture

Every statement above carries its evidence class — nothing is invented.

Tech stack

  • Tauri (Rust shell)
  • Rust
  • Web frontend
  • Local on-device storage
  • Peer synchronisation
  • Inno Setup

Want to go deeper on Construction ERP?

I'm happy to walk through the architecture and the decisions behind it.

Get in touch