Rodney Dela Cruz

BarangayOS

Offline-first web app for Philippine barangays: digital record-keeping and finance modules that keep working when the connection does not.

Rodney Dela Cruz

Technical Co-founder, eSerbisyo

  • Next.js
  • TypeScript
  • Offline-first sync
  • PostgreSQL
BarangayOS dashboard for a Philippine barangay record-keeping system.

BarangayOS digitises the paper record-keeping that a Philippine barangay hall runs on, and keeps running when the internet does not. That second half is the part that decides whether it is used at all.

A barangay hall is not a weak version of an office. It is a different environment: intermittent connectivity, one shared device, staff who are not IT, and records that must be retrievable today whether or not the connection cooperates.

What “offline-first” has to mean here

Offline-first is usually a performance feature. For a barangay hall it is the adoption requirement — a system that fails when the signal drops gets abandoned by the second week, and no amount of good UI recovers that.

The practical consequences:

  • A clerk can record a transaction, a document request, and a resident’s details with the network off, and the records are not lost or silently queued in a way nobody can see.
  • Sync is explicit and visible. A user needs to know what has landed and what has not, without opening a log.
  • The last-write-wins conflicts are confined to records a single clerk owns, because shared ledgers are exactly where that strategy fails.

What the finance module actually needs

Barangay finances are not an accounting problem with a local accent. They are a records problem with an audit requirement attached: a collection has to be traceable to who received it, when, under what document number, and it has to still be reconstructible a year later.

That rules out designs where the ledger is a derived view over a log. The ledger is the record; the log is how you explain it.

What is still rough

The reconciliation path is manual. If two clerks record the same document number while offline, the conflict is flagged rather than resolved, and a human settles it. That is the correct behaviour, but it is a workflow, not a feature, and it needs a better interface than a flagged row.

Why it is open source

Because the failure modes above are known. Someone else building for a barangay hall should not have to rediscover that an offline queue nobody can inspect is worse than no offline mode at all.