A ward office that answers back.

A Nairobi ward is the level of government residents actually touch. It is where a blocked drain gets reported, where a parent applies for school fees support, where road works either happen or don't. Yet the office that handles all of this typically runs on paper registers, phone calls, and the recollection of whoever was on duty.

The result is structural, not personal. A complaint that isn't written down can't be followed up. A bursary decision that isn't recorded can't be explained. Residents have no way to check what happened to their request, and the office has no way to see its own workload, so it can't prove it is doing the work even when it is.

The brief was to give the ward the same operational visibility I build for hotels and logistics companies, and to design it so the next ward can deploy it without starting over.

The core mechanism is simple: every report gets a tracking ID at the moment it's submitted, like CMP-2026-4817. The resident keeps the ID; the office can't quietly lose the request. Status moves through three states, each with a published service target, and the resolution note is written for the resident, not just for the file.

Ward bursaries are one of the most visible things local government does, and one of the easiest to question. The application form captures what a reviewer actually needs to allocate fairly: total fees, amount already paid, amount requested, education level, and sub-location. Every decision carries a review note, and the applicant sees it.

Because the data is structured, the office can finally answer the questions that matter: how much was requested against how much was approved, and whether support is reaching every part of the ward or clustering in one.

Most wards don't have a usable map of their own territory. The platform includes a GIS layer fed by community enumerators using KoboToolbox: water points, sanitation, schools, health facilities, markets, drainage, and household records. Submissions come in as CSV and every point keeps its provenance: submission ID, who collected it, when, and whether a staff member has verified it.

The sensitive part is households: size, tenure status, water, power and sanitation access. That data is essential for planning and dangerous if exposed. So the rule isn't in the interface, it's in the database: the public can only ever read verified, non-household points. Household records are visible to authenticated staff only, and no frontend bug can change that.

Small offices usually get one shared admin password. That makes every action anonymous and every mistake unrecoverable. Instead, each staff account carries eleven independent permissions, assigned by a super-admin, and the console only shows what a person is allowed to touch. A clerk can log complaints without approving bursaries; a reviewer can approve bursaries without deleting records.

The reports view turns operational data into the picture a ward office has never had: complaints by category and status, resolution rate, submissions over time, bursary demand by education level and sub-location, and total requested against total approved. It exports to CSV for county reporting.

On top of that, one click sends an aggregated summary, never raw records, to Claude, which writes a short plain-language brief for staff: which categories are rising, where response is slow, and where support looks unevenly distributed. The point is not automation for its own sake. It's giving a busy office the one paragraph it would otherwise never have time to write.

Public institutions can't afford clever systems that only their builder understands. The stack is deliberately mainstream: a Next.js app on Vercel, Postgres on Supabase with authentication, and access rules written as row-level security policies so the database, not the app, is the last line of defence. The whole schema is four readable SQL migrations.

The measure of a civic platform isn't whether it works in one ward. It's whether the next ward can run it without the person who built it. These are the decisions that follow from that.