Civic technology is the use of digital tools, data, and design methods to improve public decision-making, service delivery, and democratic participation. It sits at the intersection of election administration, public benefits delivery, digital identity, algorithmic accountability, and community-owned infrastructure. For practitioners who are skeptical of the sector’s own hype, the question is not whether civic tech can do good. The question is whether we can measure what it actually does to people, especially those who are already excluded from public systems. This article argues that the field’s dominant success metrics—uptake, engagement, and user satisfaction—are too weak to carry the weight of democratic accountability. We need metrics that capture exclusion, power shifts, and the durability of public trust.
The Problem with Counting Clicks and Smiles
Most civic tech projects report success in three ways: how many people used the tool, how often they returned, and whether they said they liked it. These are borrowed from consumer software, where the goal is to maximize time on platform. But a public benefits portal is not a streaming service. A voter registration app is not a social network. When we measure civic tech like a product, we optimize for the wrong things.
Consider a city that launches an online portal for reporting potholes. The dashboard shows 10,000 reports in the first month. The team celebrates. But the metric hides who reported, from which neighborhoods, and whether the city actually fixed the potholes. It also hides who could not use the portal at all: people without reliable internet, people who do not read English well, people who fear that reporting a pothole will draw attention to their immigration status. The success metric is not just incomplete; it is actively misleading.
This is not a hypothetical. Researchers studying 311 systems in multiple U.S. cities have found that digital reporting channels skew toward wealthier, whiter neighborhoods, even when the underlying infrastructure problems are worse elsewhere. The tool appears successful because it is used. But the metric of use measures access, not justice.
What Success Metrics Should Do in a Democratic Context
In a democracy, public technology has a different job than commercial technology. It must be legible, accountable, and non-exclusionary. That means success metrics should answer three questions:
- Who is left out? Not just who used the tool, but who could not, and why.
- Who has more power now? Did the tool shift decision-making toward communities, or did it concentrate control in a vendor or a central agency?
- What broke, and who fixed it? Did the system fail in predictable ways, and were there clear paths for redress?
These questions are harder to measure than clicks. They require disaggregated data, qualitative research, and a willingness to publish negative results. But they are the only metrics that matter if the goal is democratic infrastructure, not just digital convenience.
Three Metrics That Actually Measure Democratic Health
1. Exclusion Rate, Not Adoption Rate
Adoption rate tells you how many people used a tool. Exclusion rate tells you how many people could not use it, even though they were eligible or affected. For a public benefits application, the exclusion rate might be the share of eligible applicants who started the process but did not complete it, broken down by language, disability, income, and geography. For an online voter registration system, it might be the share of eligible voters who attempted to register but were blocked by an address-matching error or an ID verification failure.
Measuring exclusion requires defining the denominator. That is hard, but not impossible. Agencies can compare digital uptake against census data, administrative records, or in-person service patterns. They can run usability tests with people who have low digital literacy, limited English, or assistive technology needs. They can publish the results. The point is not to eliminate exclusion—no system is perfectly inclusive—but to make it visible and to set a target for reducing it.
2. Power Shift Index
Most civic tech projects claim to give residents more power. But power is not a feeling; it is the ability to make binding decisions. A power shift index would track whether a tool moves decision-making authority from a government agency to a community body, from a vendor to a public owner, or from a centralized office to a neighborhood group.
For example, a participatory budgeting platform might report how many residents voted on budget proposals. But the power shift index would ask: Did the winning proposals actually get funded? Did the community have control over the agenda, or only over a pre-selected menu? Did the process change who holds budget authority in future cycles? If the answer is no, the platform is a consultation exercise, not a power shift.
This metric is deliberately uncomfortable. It forces project teams to admit when they are building feedback mechanisms rather than governance mechanisms. But that honesty is exactly what the field needs.
3. Redress Time
Public systems fail. People are denied benefits they qualify for. Voters are purged from rolls by mistake. Algorithms flag the wrong household for investigation. What matters is not whether the system fails, but how long it takes to fix the failure and whether the person affected has a clear path to appeal.
Redress time measures the gap between when a person reports an error and when the error is corrected, with the person’s rights restored. It should be tracked for every automated decision, every identity verification failure, and every benefits denial. A system that denies benefits quickly but takes six months to correct a wrongful denial is not a success, no matter how many people use it.
Redress time also captures the human cost of automation. When a computer says no, a person should be able to say, “Check again,” and get a timely, human review. If the metric is missing, the system is designed for the convenience of the agency, not the dignity of the person.
Why the Field Resists Better Metrics
If these metrics are so obviously necessary, why does civic tech keep measuring clicks? The answer is structural. Many civic tech projects are funded by foundations or venture capital that want to see growth curves. Many are built by vendors who are paid for delivery, not for outcomes. Many are evaluated by agencies that do not want to publish data showing that their digital transformation left people behind.
There is also a cultural problem. The civic tech field has a strong bias toward optimism. We like stories of residents coding their way out of a problem, of hackathons producing apps that “disrupt” bureaucracy. Better metrics would force us to tell harder stories: about the person who could not use the app, the neighborhood that was not represented, the algorithm that made a mistake and took months to fix. Those stories do not fit neatly into a demo day pitch.
But the field’s credibility depends on telling them. If civic tech cannot measure exclusion, it cannot claim to reduce it. If it cannot measure power shifts, it cannot claim to build community power. If it cannot measure redress, it cannot claim to be accountable.
What Better Metrics Look Like in Practice
Some public agencies and community organizations are already moving in this direction. The City of Boston’s digital services team has published equity assessments for major online services, including disaggregated data on who uses them and who does not. The Detroit Digital Justice Coalition has developed principles for community-owned internet infrastructure that include metrics for local control and affordability, not just speed and coverage. The Algorithmic Justice League has pushed for algorithmic impact assessments that include redress mechanisms and community oversight.
These examples are not perfect. They are often underfunded, politically contested, and slow. But they show that better metrics are possible when the people who design the metrics are accountable to the people who are affected by the technology.
For practitioners, the practical steps are clear. First, define the population that should be served, not just the population that is easy to reach. Second, collect data that can be disaggregated by race, income, language, disability, and geography. Third, publish the results, including the failures. Fourth, tie funding and contract renewals to exclusion rates, power shift scores, and redress times, not just to uptime and user counts.
The Cost of Not Measuring
When civic tech measures the wrong things, it does not just waste money. It deepens inequality. A digital benefits portal that works well for people with broadband and English literacy but fails for everyone else is not a neutral tool. It is a new barrier, dressed in the language of modernization. A voter registration system that silently drops applications with address mismatches is not a convenience. It is a form of disenfranchisement, hidden behind a clean interface.
The people who are most affected by these failures are rarely in the room when the metrics are chosen. They are the ones waiting on hold, the ones who cannot get an appointment, the ones who give up. Better metrics are a way of bringing them into the room, or at least making their absence visible.
This is not a call for more data for its own sake. It is a call for data that serves accountability. The goal is not to build a perfect dashboard. The goal is to build a public record of who is served, who is excluded, and who has the power to fix it.
Frequently Asked Questions
Why do civic tech projects usually measure adoption and satisfaction?
Because those metrics are easy to collect and easy to present to funders. They come from commercial software culture, where growth and user happiness are the primary goals. But in a public context, adoption can hide exclusion, and satisfaction can hide powerlessness. A person can be satisfied with a tool that still leaves them dependent on a vendor or an agency for every decision.
What is an exclusion rate, and how is it different from a digital divide statistic?
An exclusion rate is specific to a particular service or tool. It measures the share of eligible or affected people who could not use the tool successfully, and it is broken down by the reasons for exclusion: language, disability, income, geography, or design failure. A digital divide statistic is a general measure of who has internet access. An exclusion rate is a measure of who was left out of a specific public process, even if they had internet access.
How can a small nonprofit or local agency start measuring power shifts?
Start with a simple question: Who makes the final decision? If the tool only collects input, but the decision stays with the same office that made it before, there is no power shift. If the tool gives a community body binding authority over a budget line or a policy change, that is a power shift. Document the decision-making chain before and after the tool is introduced. Publish the comparison. Even a one-page memo can be more useful than a dashboard full of engagement numbers.
What is redress time, and why does it matter for algorithmic systems?
Redress time is the period between when a person reports an error in an automated decision and when the error is corrected and the person’s rights are restored. It matters because algorithmic systems can fail at scale, and a fast denial with a slow appeal process is a form of administrative violence. A system that cannot correct its own errors quickly is not accountable, no matter how accurate its aggregate statistics look.
Next Steps for This Publication
This article is the first in a recurring series on civic tech evaluation. Future pieces will examine specific tools: how to audit a public benefits portal for exclusion, how to design a power shift index for participatory budgeting, and how to build redress time into algorithmic impact assessments. If you are working on these questions in your own agency or community, send a note through the contact page. The goal is to build a shared, public record of what works, what fails, and who is left holding the consequences.
