Digital City Hall PWA

An end-to-end progressive web app for municipal operations: citizens request and pay for services on the public side, departments process them on the administrative side, and the finance module keeps the record of both.

It is the most complete of the local-government builds because it is the only one that treats the whole loop — request, approval, payment, record — as one system rather than three tools and a folder.

Why a PWA for a municipal office

Installability and offline behaviour are the two reasons. An office installs it once and it runs from the home screen, which sidesteps the browser and OS problem that kills most government-adjacent tools — nobody maintains the browser.

Offline matters because municipal work does not stop when the uplink does. A front-desk clerk taking a request during an outage is a better outcome than a clerk telling someone to come back tomorrow.

The citizen side is the load-bearing half

Self-service only pays for itself if it removes a queue rather than adding a digital one in front of the old one. The requirement that shaped the design: every request a citizen can complete alone must complete alone, without anyone at the counter touching it.

That means the public side carries its own validation, its own status, and its own document delivery. The counter is for the cases that genuinely need a person.

Role-based controls across departments

Departments share records. Finance, planning, and the clerk’s office all touch the same documents with different rights, and the permissions have to be granular enough that a department can run its own workflow without being able to edit another department’s.

The failure this prevents is the mundane one: an administrative convenience that quietly becomes a permission escalation because one role inherited broader access than it needed.

Financial tracking, deliberately not an accounting system

The finance module tracks collections against budget lines and produces the reports a municipality is expected to file. It is not a double-entry ledger and does not pretend to be.

The honest reason: municipal reporting needs traceability to a document number and a collector, which is a records problem, and retrofitting statutory accounting onto it would have produced something that satisfies nobody.

What is still missing

Notification delivery is the weak point. A citizen who is not told their document is ready will phone the office, so the workflow is only as good as the message. It needs a delivery channel that does not depend on the citizen having notifications switched on.