One connected system for every office of a town hall, as a prototype

The problem

In a small municipality, most services still run on paper. A citizen who needs a permit, a certificate or a tax declaration walks from office to office, and staff pass files by hand between the Treasury, the Assessor, Accounting, the Mayor and others. Nobody can see where a request is stuck. I wanted to show the Municipality of San Francisco what one connected system could look like: each office with its own workspace, every hand-off visible, and citizens able to request, pay and track online. e-Serbisyo is that proposal and a working prototype of it.

Constraints

• Mock data only. No real taxpayer records until a local government signs a data-processing agreement. Every visitor gets their own sample copy in the browser.
• Law first. Fees, signatories and deadlines follow the national local government code, state audit rules and data-privacy law. Rules not yet confirmed with the office concerned are marked as samples.
• Handover to a small IT office. Staff who did not build it must be able to run and maintain it, so every block of code is explained in plain English.
• Basic computer users. Plain language, one clear next action, large touch targets, light and dark themes, phone layouts.

What I did

Strategy and brand

I wrote the proposal package (transmittal letter, technical and financial volumes, a training guide) and an internal master blueprint covering roles, workflows, timelines and integrations. The proposal names 7th Devs Tech as the delivering company. I also drafted a legal and policy pack, marked throughout as a draft for a lawyer to review.

Design

I designed office-by-office sign-ins, a left menu with one page per desk, guided tours on every screen and a Training Guide that shows each office only what applies to it.

Engineering

The prototype has 20 office workspaces. It links the offices through chains of work: building and occupancy permits, transfer of property ownership, travel cash advances, leave, hiring, first salary and terminal leave, and the Treasury's daily cash count and report of collections. Money is stored in whole units of the smallest coin, receipts come from a controlled series, and nothing financial is deleted. It also includes a tax map in Leaflet, QR codes on documents and a PostgreSQL and PostGIS schema for the production version. One Python command rebuilds the user manual, developer guide and code reference from the app's own code.

AI

The prototype has an AI receptionist with voice. A rules engine finds the facts, and a model (Claude, a local Ollama model, or none) words the reply.

The bigger AI work is how the project was delivered. I designed and directed a team of specialized AI agents in Claude Code that ship real work. A 10-role kit (PRO, WFA, ARCH, INFRA, BDEV, FDEV, INTG, SPO, QA and MOD) sets a fixed flow for each new service: policy research, workflow mapping, architecture, infrastructure, backend, frontend, integrations, security and privacy review, testing and a learning module. Each agent must cite sources, record decisions and write a lesson next to its code. The prototype repo runs its own team of 13 agents, including one that keeps every code block commented. My part was defining the roles, the order of work and the checks between them.

Outcome

A working prototype on mock data, shown as a pitch demo. It went through 42 tagged versions in about two weeks (October to November 2026). It has 20 office workspaces, 12 documented workflows and 39 mapped hand-offs between offices, and a forensic check found every code block commented. It has not been adopted or used by the municipality or any other local government, and nothing about its effect on service times has been measured.

What I'd change next time

I would get the municipality's own fee schedules and staffing list earlier, because many screens still carry sample rules waiting for confirmation. I would also build the real backend sooner, since the browser-only store hides the hardest problems of syncing data between offices.