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. They don't have the institutional knowledge to evaluate code, manage deployments, or maintain systems over time. The expertise simply isn't in the building.
This was true, and it shaped an entire generation of municipal technology procurement. If you can't build it, you buy it. If you can't maintain it, you subscribe. The vendor model wasn't just convenient — it was the only realistic option for organizations that employ planners and clerks and code enforcement officers, not developers.
But something has shifted in the last two years that most municipal leaders haven't fully absorbed yet. AI-assisted development tools — Claude Code, GitHub Copilot, OpenAI Codex, and others — have dramatically lowered the skill threshold for building and maintaining software. A technically minded city employee who couldn't have built a web application three years ago can now scaffold, deploy, and iterate on one with AI assistance. The quality ceiling has risen and the entry barrier has dropped simultaneously.
This doesn't mean every city clerk should start writing code. It means the gap between “we need a full software engineering team” and “we have a few technically capable staff” has narrowed to the point where the vendor dependency model deserves serious reexamination. The question is no longer “can we build this?” It's “do we know what to build, and do we have a framework for doing it well?”
What municipalities are actually buying
When a mid-size city signs a $14,000 annual contract for FOIA request management software, what are they getting? A web form for intake. A queue with workflow states. A deadline tracker. Email notifications. A reporting dashboard. Document storage with basic redaction.
Every one of those components exists as open-source software, tested and maintained by communities of thousands of developers. The form is a solved problem. The queue is a solved problem. The deadline tracker is a solved problem. Even document redaction — the most technically demanding piece — has mature open-source libraries that handle it reliably.
What the vendor provides isn't technology. It's assembly and accountability. They took commodity components, configured them 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.
From human-centered design to agent-centered design
The conversation about municipal technology has rightly focused on human-centered design — building tools that work for the people who actually use them, not just the IT department that procures them. That principle doesn't change. What changes is who's using the tools.
We're entering a period where municipal workflows won't just be executed by human staff using software. They'll be executed by AI agents working alongside staff — agents that can draft responses to routine records requests, flag approaching deadlines, pre-screen documents for sensitive information, and route complex cases to the right department. This is already technically possible. The question is how it gets implemented.
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. The same lock-in dynamic that governs today's software will extend to tomorrow's AI layer — except the stakes will be higher, because agents make decisions that affect residents.
If agent-centered design is led by open standards and municipal ownership, the outcome is different. The city controls the agent's configuration. The governance rules are inspectable. The AI model is swappable — if one provider's model is more accurate or less expensive, the city can switch without rebuilding the system. The agent works for the municipality, not for the vendor.
This isn't hypothetical. The architectural choice between vendor-locked agents and open, model-agnostic agent infrastructure is being made right now, in the design decisions of every civic tech tool under development. The municipalities that understand this choice will have leverage. The ones that don't will discover in five years that their AI vendor has the same grip on their operations that their SaaS vendor has today — except deeper, because the agent doesn't just store data, it shapes decisions.
What “owning the stack” actually looks like
Municipal digital infrastructure doesn't mean every city needs a server room. Just as Chattanooga's fiber network uses standard telecommunications equipment configured for a public mission, municipal software infrastructure uses standard open-source components configured for government context.
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. The hosting can be cloud-based. The components can be open-source and community-maintained. But the orchestration — the part that says “this is how our city processes a records request” — that should belong to the city, not to a vendor's proprietary configuration that the city can't see, modify, or take with them.
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.
Practically, this looks like:
Open-source base.
The core software is free to use, inspect, and modify. The city can see every line of code that handles its residents' data.
Configurable governance.
The rules that determine how the system behaves — response deadlines, approval workflows, redaction policies, agent permissions — are set by the municipality, not compiled into vendor software that can't be changed without a support ticket.
Model agnosticism.
When AI capabilities are part of the system, they connect through open interfaces rather than hardcoded vendor integrations. If a city is using one AI model today and a better one is available tomorrow, switching is a configuration change, not a migration project.
Portable data.
If the city decides to change how it manages a workflow — different software, different partner, or fully in-house — its data comes with it. No export fees, no proprietary formats, no discovering that years of institutional knowledge is locked in someone else's database.
Supported, not abandoned.
Open-source doesn't mean unsupported. The model that works is a partnership between the municipality and an organization that provides implementation, configuration, maintenance, and training — but where the city owns the infrastructure and the partner works for the city rather than the other way around.
The workforce question, revisited
This brings us back to the expertise gap. The argument was always: cities can't hire developers, so they can't own software. With AI-assisted development, we need to update the question.
The new workforce model isn't “every city hires a software engineer.” It's “every city has staff who understand their workflows deeply, and those staff can now collaborate with AI tools to configure, adapt, and maintain systems that would have previously required a dedicated development team.”
The person who knows how your city's FOIA process actually works — every exception, every interdepartmental handoff, every edge case the vendor's default configuration handles wrong — is already on your payroll. They're the city clerk who's been doing it for fifteen years. What they couldn't do before was translate that expertise into software. What's changing is that translation is getting dramatically easier.
This doesn't happen overnight, and it doesn't happen without support. But it changes the calculus from “we need something we'll never have” to “we need to develop a capacity we can actually build.” That's a meaningful difference for any city manager weighing the next five years of technology investment.
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.
Dustin Good is the founder of CivicWork, Inc. and an at-large city councilmember in Elgin, Illinois. CivicWork builds open-source AI infrastructure for local government. Learn more at civicwork.ai.