The weekend I rebuilta city’s website.

Brownsville is having a moment. It’s the city SpaceX launches Starship from, it sits on the Gulf coast, and roughly 186,000 people live there. Its digital front door looked like it needed a refresh.

An important thing to consider is that until less than a decade ago, city and government websites were largely informational. With advancements in technology all around, they are now increasingly transactional. For example, 15 years ago, city residents would mostly go to the city website to check addresses, phone numbers, office hours, etc. More recently, they’ve become transactional — residents can pay bills, upload documents, apply for permits, and review their own transaction history.

The current Brownsville site is more informational, a big opportunity to rethink. Navigation mirrors the city’s internal org chart instead of residents’ tasks. Spanish support is missing in a city where the Census American Community Survey puts Spanish-spoken-at-home above 80%. Finding an answer buried in the Unified Development Code means reading the Unified Development Code. There’s also a deadline attached: the Department of Justice’s new ADA Title II web accessibility rule requires cities of Brownsville’s size to meet WCAG 2.1 AA by April 2026, which has already passed.

I did not start from a blank canvas. I researched government websites, how they were being used, who launched new features or services recently, etc. The benchmark I built against was co.colorado.gov — I found it to be the best task-based government website in the country.

The single biggest decision was the information architecture. Residents don’t think “Public Works Department”; they think pay my water bill, report a pothole, find a park. So the site’s spine is a bilingual, verb-first service catalog. Every service became a task.

Three product rules followed from field research and from studying how real residents actually fail on city sites:

1. Bilingual parity, not a translate button. Every route, every string, every error message exists in English and Spanish — written Spanish in the formal usted register, authored, not machine-translated. The language toggle swaps languages on the same page.
2. Honest handoffs. Many “city” services aren’t run by the city; the water utility is BPUB, permits run through Accela. I added clarity for residents. Every external service carries an operator label: who runs it, why you’re leaving, and what you’ll need when you get there.
3. Accessibility as a floor, not a feature. WCAG 2.1 AA contrast on every surface, keyboard-navigable everything, screen-reader-correct language tags.

The marquee feature is Ask Brownsville: type a question — “How tall can a fence be in a residential district?” — and get an answer drawn from the city’s actual municipal code, with numbered citations linking to the exact sections, in English or Spanish.

The biggest blocker to cities adopting AI is trust, not capability. A city cannot deploy a system that occasionally invents an ordinance. So the assistant runs on one non-negotiable rule: every answer is grounded in retrieved sections of the city’s own code, every answer carries citations, and if the code doesn’t cover the question, the assistant says so and hands the resident to a human channel instead of guessing. The refusal behavior isn’t nice-to-have. It’s tested, and covered below.

Two stories have to be true at once:

• The private story. For a city deployment that’s really private, nothing about a resident’s question should have to leave the building. So the engine runs on Ollama with open-weight models — qwen2.5:7b-instruct for answers, nomic-embed-text for embeddings — on hardware the city owns. The 10/10 golden-set score above is on exactly this configuration.

A lot. Highlights from the adversarial red-team pass I ran on my own product — a live hostile-browser session plus a code-level review that produced 41 findings, all fixed before launch:

• The 42-second wall of silence. On the local 7B model on my Macbook Air M4 w 24GB memory, a full answer took a measured 42 seconds, and the UI’s wait copy stalled at “Reading the sections…” with no elapsed-time signal and no cancel button. A hung stream locked the whole app. Fixed: cancel mid-stream, staged progress copy, and streaming that shows tokens as they arrive.
• Error dead-ends. The error copy said “use the official channels below” and rendered zero channels. Raw internals (“Could not resolve authentication method...”) surfaced verbatim, in English, inside the Spanish interface. Fixed: localized error cards with human handoff channels and a retry button on every failure path.
• The trust badge failed accessibility! The green “Grounded in cited sources” badge — the product’s core trust signal — tested at 4.01:1 contrast, just under the 4.5:1 AA threshold. The one element that most needed to be legible wasn’t.
• Hallucinated refusal. The system watches for a refusal sentinel when the corpus doesn’t cover a question. During verification, the model invented its own sentinel — answering a Spanish question with “NO_SE_INFORMA_SOBRE_ESTE_TEMA” followed by eight fabricated citations. It evaded the guards because it wasn’t the sentinel we were watching for. The fix: a detector for ALL-CAPS snake-case pseudo-sentinels, plus regression tests. The lesson: guardrails need guardrails, and the failure modes you enumerate are never the complete set.

What held up under attack is worth noting too: script injection rendered inert as literal text, and questions wrapped in garbage still retrieved and answered correctly (“35 feet, cited”).

City manager stuff: All numbers below are estimates with stated assumptions, deliberately widened toward the expensive end rather than the cheap one; check my arithmetic, and read the scope caveat above first, since these tiers still price the narrow 222-section corpus, not a full-code deployment.

Usage assumptions. Brownsville has roughly 186,000 residents. Two real cities give an anchor for 311-style contact volume: Chicago logged about 654,500 service requests in the twelve months to May 2026 against a population of roughly 2.7 million — about 0.24 requests per resident per year; NYC311 logged about 2.7 million requests in 2018 against roughly 8.3 million residents — about 0.33 per resident per year. Applied to Brownsville’s population, that’s roughly 45,000 to 61,000 contacts a year, 3,750 to 5,000 a month, across all channels combined.

That anchor almost certainly understates the real number: 311 datasets only count logged service tickets, not the much larger volume of informational questions residents ask a front desk or a phone line that never becomes a ticket at all. “How tall can my fence be” doesn’t get filed — it gets answered, or the resident gives up. Comparable deployments back that up: Williamsburg, VA’s city chatbot resolved 79% of resident questions on first contact; Phoenix’s myPHX311 assistant fields service requests, utility on/off included, without a human. Neither city publishes a hard per-capita AI-assistant query count I can cite, but the direction is consistent: once a low-friction, always-on, bilingual channel exists, usage runs toward the high end of what 311 data alone implies, not the low end. I’ve modeled three tiers against that wider, sourced range, not a top-of-head adoption percentage:

Per-query token math. Each answer sends the model a system prompt plus about 8 retrieved code sections — roughly 5,000 input tokens — and generates a roughly 400-token answer. That figure is calibrated to the 222-section corpus in this build. A full 348-chapter corpus spanning many more topics would likely need a wider retrieval window, more candidate chunks, possibly a category-routing step before retrieval, to hold answer quality across that many more subjects, which pushes input tokens per query up from this baseline. I don’t have a measured number for that larger corpus, so the cost tables below are a floor for Option 1, not a ceiling.

Option 1: Public API

At Claude Sonnet 5’s list price ($3 per million input tokens, $15 per million output), a query costs about 2.1 cents (5,000 tokens times $3/M, plus 400 tokens times $15/M). Anthropic’s current introductory pricing ($2/$10 through August 2026) brings that to roughly 1.4 cents. Prompt caching the fixed system prompt shaves roughly another 20 percent.

Option 2: Private cloud (a GPU VM in the city’s own cloud account)

One GPU instance runs the whole stack — open-weight model, embeddings, database — inside the city’s VPC. Current AWS on-demand pricing: a g6.xlarge (NVIDIA L4, comfortable for a 7 to 14B model) runs about $0.80 an hour, roughly $588 a month running 24/7; the older g5.xlarge is about $1.01 an hour, roughly $734 a month. A one-year commitment typically cuts that by roughly a third, into the $350 to $450 range. Add roughly $40 to $60 for storage, snapshots, and egress.

Option 3: Fully self-hosted (the city’s own hardware)

The maximum-privacy option: a single GPU workstation in the city’s server room. Assumptions: roughly $3,500 one-time for an RTX 4090-class machine, amortized over 3 years (roughly $97 a month); roughly 300W average draw times 730 hours times $0.13/kWh Texas commercial power, roughly $28 a month.

The obvious next question: strap a speech-to-speech model onto this — Amazon Nova 2 Sonic, OpenAI’s Realtime API, or Google’s Gemini Live — and let residents talk instead of type. The pricing is real and checkable. The harder part is that voice isn’t a cost line one can add to the existing model; it’s an architecture decision that touches the guardrail stack that’s the actual product here.

The architecture choice. All three vendors are audio-native reasoning models, not text-to-speech bolted onto a fixed pipeline. That gives two real options:

1. Let the voice model be the LLM. Fastest, and the pricing below applies directly. But then citation grounding, the refusal sentinel, the retrieval-score floor — the whole guardrail stack covered above — has to be rebuilt inside a live audio session. All three vendors support mid-session function/tool calling, so in principle the existing retrieval engine can be wired in as a callable tool. In practice, context window is an issue. Besides, none of the three vendors’ documentation shows a production example of a similarly-scoped assistant reliably citing sources and refusing out-of-corpus questions by voice.
2. Build voice around the existing pipeline. Speech-to-text converts the resident’s question, the existing grounded RAG call answers it exactly as it does today (same 10/10 golden set, same refusal sentinel, same citation check), and text-to-speech reads the answer back. Nothing about the trust architecture changes. The cost is additive: audio I/O on top of the per-query model cost already priced above. Latency goes up by one extra hop, and native mid-sentence barge-in is harder to support well in a cascade — but the guardrails that are the actual point of this build stay intact and already-tested.

Given that the whole pitch of this assistant is “it doesn’t make things up and it says when it doesn’t know,” the cascaded architecture is the responsible default. Native reasoning is worth revisiting once one of these vendors publishes a grounding/refusal pattern that’s actually been red-teamed for this.

What each vendor actually costs and supports, at 2026 published rates:

What it costs layered on the existing tiers, assuming a ~50 to 60 second round trip per voice query (a ~12-second spoken question, a ~35 to 40-second spoken answer — the citation-laden answers this assistant gives take longer to say than to read) and Gemini Live as the audio layer around the existing text pipeline:

One gap worth naming rather than papering over: every number above is a metered cloud API. Unlike the text half of this build, there’s no mature open-weight speech-to-speech model I can price for the self-hosted or private-cloud columns — the open alternatives exist but aren’t at a point I’d cite a production cost for.

Voice, as of today, doesn’t get cheaper by owning the hardware the way text generation does. That tips the calculus back toward “pace the rollout and watch the meter” for voice specifically, even for a city that’s otherwise committed to self-hosting the text assistant.

Any city, a university’s student policies, or a hospital’s administrative code, is a YAML profile, an ingestion source, and a ten-question golden set. The recipe is mostly above.

If you are working on something similar, or you’re a city wondering what AI could do for your residents without losing their trust, I’d love to connect and show the actual build.