There's a useful question that almost never gets asked in city budget meetings: why does your municipality own its water treatment plant but rent its public records system?
It's not a trick question. The water plant is critical infrastructure. It has to work every day, it serves the entire community, it's subject to regulatory requirements, and failure has real consequences. A city employs or contracts the people who maintain it because the alternative (depending on a single private company with no obligation to keep the price stable or the service running) would be an unacceptable risk to public health.
Now describe the software that manages your FOIA requests, your permitting workflows, your council agendas, your 311 system. It has to work every day. It serves the entire community. It's subject to regulatory requirements. And failure has real consequences: missed public records deadlines mean legal liability, broken permitting systems mean stalled development, inaccessible council documents mean eroded public trust.
Yet the default model for municipal software is the one we'd never accept for physical infrastructure: total dependency on a vendor who owns the system, controls the data, sets the price, and can change the terms at renewal.
What Chattanooga got right, and what it didn't finish
When Chattanooga built its municipal fiber network in 2010, it was treated as radical. A city-owned gigabit internet service, competing with private ISPs? The business community warned it would fail. The incumbents sued to stop it. Fifteen years later, Chattanooga's network is a case study in what happens when a municipality treats connectivity as public infrastructure rather than a private service. The network is self-sustaining, it's attracted billions in economic development, and it gives the city control over a resource that most communities have surrendered entirely to two or three national carriers.
But Chattanooga built the pipes. It didn't build what runs through them.
The city still depends on the same SaaS vendors as everyone else for the software its departments use daily. The fiber network solved the connectivity layer. The application layer (the actual tools staff use to serve residents) remains rented, proprietary, and locked into vendor ecosystems where the city's own operational data is treated as someone else's asset.
This isn't a criticism of Chattanooga. It's a description of where every municipality stands. Even the most infrastructure-forward cities in the country own their physical networks but rent their digital workflows. The model is incomplete.
The expertise gap was real. It may not be anymore.
For decades, the obvious objection to municipal software ownership has been workforce. Cities can't hire software engineers. They can't compete with tech-sector salaries. The vendor model wasn't just convenient. It was the only realistic option for organizations that employ planners and clerks, not developers.
That gap is narrowing. AI-assisted development has lowered the skill threshold for building and maintaining software. The person who knows how your city's FOIA process actually works, every exception, every interdepartmental handoff, can now participate in configuring the system that manages it. This doesn't mean every city clerk should start writing code. It means the question has changed from “can we build this?” to “do we know what to build, and do we have a partner who can help us do it well?”
What municipalities are actually buying
When a mid-size city signs a $14,000 annual contract for FOIA request management software, the underlying technology is commodity: open-source databases, standard web frameworks, cloud hosting anyone can rent. What the vendor provides isn't technology. It's assembly and accountability. They configured commodity components for a government context and attached a phone number for when something goes wrong.
That has real value. But it's not $14,000-a-year-with-no-data-portability value. And it's certainly not $78,000-a-year value, which is what some state agencies pay for the same fundamental system. The premium isn't for complexity. It's for the absence of alternatives.
From human-centered design to agent-centered design
The ownership question becomes more urgent as AI agents enter municipal workflows. If agent-centered design is led by vendors, the agents will be proprietary, locked to specific models, and bundled into existing subscription contracts. The city won't be able to inspect what the agent is doing, verify its reasoning, or switch to a different AI model if a better one emerges.
If the city owns the infrastructure, the dynamic inverts. The governance rules are inspectable. The AI model is swappable. The agent works for the municipality, not for the vendor. This choice, between vendor-controlled agents and city-controlled infrastructure, is being made right now in the design of every civic tech tool under development.
What this means in practice, from document formats to governance rules to the infrastructure decisions that determine whether municipal AI is transparent or opaque, is explored in depth in Agent-Centered Design.
What “owning the stack” actually looks like
Municipal digital infrastructure doesn't mean every city needs a server room. The hosting can be cloud-based. The components can be open-source and community-maintained. What a city needs to own is the decision layer: the configuration that determines how its data flows, what its agents are authorized to do, what governance rules apply, and where the human review points are.
This is analogous to the distinction between owning a building and owning the blueprints. You might hire a contractor to do the work, but if the contractor keeps the blueprints, you're dependent on them for every future renovation. Municipal digital infrastructure means owning the blueprints: open-source code you can inspect, portable data you can take with you, governance rules you set, and the ability to change partners without starting over.
What the support model for this looks like in practice, how a city gets the benefits of ownership without bearing the full maintenance burden alone, is the subject of Not a Vendor. Not DIY.
Questions worth asking at the next budget meeting
Municipal leaders don't need to become technologists to make better decisions about digital infrastructure. They need to ask better questions of the vendors and advisors already in the room:
If we decided to leave this vendor next year, what happens to our data?
If the answer involves export fees, proprietary formats, or the phrase “we'll work with you on a transition plan,” that's a lock-in signal.
Can we see the code that handles our residents' information?
If not, you're trusting a black box with public data. Every other form of municipal infrastructure is subject to inspection.
Is the AI built into this product locked to one model?
If the vendor's AI features only work with their proprietary model, you're buying a dependency, not a capability.
What would it cost to build this ourselves with open-source tools?
You may be surprised. For many common municipal workflows, the answer is “less than you're paying now, and you'd own it.”
What does our staff know that this software doesn't?
The deepest institutional knowledge in any city lives in the people who do the work. If the software can't be adapted to match how your organization actually operates, because only the vendor can make changes, you're paying to work around your own tools.
None of these questions require a technology background. They require the same judgment municipal leaders apply to every other infrastructure decision: who owns it, who controls it, what happens when something breaks, and what does it cost over ten years, not just one.