A Local-First Permit Tracker

Planning permission is one of those processes where the gap between what citizens expect and what the system delivers is wide enough to drive a lorry through. Most councils publish application data on creaking portals that were procured a decade ago. Residents trying to track what is happening on their street, or campaigners monitoring development patterns across a borough, are left refreshing pages and copying information into spreadsheets.

We have been building something smaller and, we think, more useful: a local-first permit tracker. It is a lightweight tool that downloads planning application data from a council's open data feed, stores it on the user's device, and lets them search, filter, and receive notifications about changes. No cloud account. No vendor lock-in. The data lives with the person who needs it.

Why local-first matters

The dominant model for web applications assumes a central server that owns the data and a client that borrows it. This works fine until the server goes down, the provider changes its pricing, or someone decides the service is no longer worth maintaining. For civic tools the risks are sharper. The council might switch portal vendor and break every downstream integration. A campaign group's research database might disappear when the grant funding runs out and the cloud bill stops getting paid.

Local-first architecture inverts this. The authoritative copy of the data sits on the user's device. Sync happens peer-to-peer or through a relay, but the user is never locked out of their own information. If the service disappears, the data and the tool remain. This is not a new idea. CouchDB and PouchDB were demonstrating it a decade ago. What is new is the maturity of the protocols — Conflict-free Replicated Data Types, the Automerge and Yjs libraries, the steadily improving support for offline-first web applications in modern browsers.

The trade-offs are real

Local-first is not free. Syncing data between devices without a central authority is harder than pointing everything at a database. Conflict resolution is a genuinely difficult computer science problem, and the tools that handle it are still young. Search across large datasets is slower on a phone than on a server. And the user experience of "works offline, syncs later" takes careful design to avoid confusion about what data is current.

There are also political trade-offs. A local-first tool hands control to the user, which means it also hands over responsibility for data quality, backup, and security. For some use cases — medical records, sensitive personal data — that is a feature. For others it is a liability. The decision about whether a given tool should be local-first is as much about who should bear risk as it is about technical architecture.

A tool you can leave is a tool you can trust. Local-first is not the answer to everything, but for civic infrastructure it is a better starting assumption than the cloud.

We are testing the permit tracker with a small group of users in the North East. The aim is not to build a product. It is to understand what happens when you give someone a tool that stays with them, that does not quietly report on their usage, and that keeps working whether or not the council's IT department has had a good week. That understanding will shape whatever we build next.