Why a municipal resident portal doesn't need a native app

A city building a resident app usually discovers the real cost isn't the first release — it's every release after it. A new capability needs a native update, on two app stores, before a resident can use it. A channel a resident actually prefers — Telegram, WhatsApp — needs a second build of everything, running in parallel, forever.

The mechanism, not the channel

Kav doesn't treat "the app" as the product. A capability — a balance, a booking, a status lookup — is defined once against the city's own system, with three separate faces: what the model reads to decide when to use it, its typed input/output contract, and how it's actually executed against a vendor's system. None of those three faces is channel-specific. The website widget, Telegram and WhatsApp all call the identical capability.

What that means for a second channel

Turning on Telegram for a city that already has the website widget live isn't a new build — it's a new row binding the same capabilities to a new surface. Nothing about a capability's contract, the rules that govern it, or the knowledge it can draw on changes because the surface changed.

What's actually live today

The website widget and Telegram are live today; WhatsApp is implemented and turned on per municipality. None of these needed a native app, an app-store review cycle, or a second parallel implementation of the same capability.

Why it matters to a resident

A resident doesn't have to decide whether an app is "worth it" for one city service. They ask on whichever surface they already have open, and the same governed, sourced answer comes back — with nothing to download first.