Participatory Budgeting Software Used by U.S. Cities
How cities let residents directly decide where public money goes.

Participatory budgeting means residents make direct, binding decisions on how a slice of public money gets spent. A resident submits a project idea, it gets vetted for feasibility, it goes on a ballot, and if it wins, it gets built. That's the whole premise, and it depends on a specific set of software platforms to actually work at city scale.
The legal machinery behind this is more particular than it sounds. A city has to ringfence a dedicated pool of money, set rules for how residents submit and refine ideas, have staff check whether a proposal is even legally or technically possible, and get council sign-off to turn a winning idea into a real line item in the budget. That last step matters, since participatory budgeting, or PB, works alongside a mayor's budget authority and a council's approval power, running a channel through both.
The idea started in Porto Alegre, Brazil, in 1989. The first U.S. process launched in Chicago in 2009, when Alderman Joe Moore handed over a portion of his own discretionary ward funds and let residents decide how to spend it. Since then, PB has since spread to cities across the world, split between two models: district-level processes tied to one council member's budget, and city-wide processes run out of a mayor's office or a civic engagement body.
The U.S. cities running PB at meaningful scale and what their programs look like on the ground
New York City runs the largest and most layered PB operation in the country, and it's really two programs at once. PBNYC handles council capital funds; The People's Money, run through the Civic Engagement Commission, handles mayoral expense funds. In 2024, PBNYC covered 24 participating council districts voting on $24 million in capital funding for infrastructure projects.
The People's Money numbers show the scale of turnout this can reach. In the 2022-23 cycle, 208,244 ballots were cast to allocate $5 million across 46 programs. The following cycle, 2023-24, saw roughly 140,000 voters pick 20 community projects funded by $3.5 million; a bit over 31,000 voted online, and the rest cast paper ballots. Voting was offered in English plus 12 other languages. By 2024-25, the expense budget allocation had grown to $4 million, and Borough Assemblies made up of randomly selected New Yorkers helped shape the ballot before the citywide vote opened.
Zoom out to the cumulative picture and the scale gets clearer: through 2018, PBNYC had put $210 million into 706 projects, with another $180 million in city-wide improvements that PB helped spark. As of 2018, more than 99,250 residents age 11 and older had participated in PBNYC. And the equity work behind the numbers is worth pausing on: in 2022-23, the city put $1.7 million into 93 community partner organizations specifically to do grassroots outreach, reaching residents who'd historically been left out of city decision-making.
Vallejo, California, tells a different story. It became the first city-wide PB program in the U.S. after the city council set it up in 2012, right as Vallejo was climbing out of municipal bankruptcy. That context shaped everything, since transparency and rebuilding resident trust were survival requirements after a bankruptcy. Over five cycles, Vallejo allocated $8.3 million to 47 projects and engaged more than 20,000 residents. In Cycle 8, in 2023, 2,553 residents voted on just over $1 million in available funds.
Chicago has run six completed voting cycles across 12 wards, with more than 26,000 residents deciding around $31 million across over 160 projects. Other cities show the range of what's possible: Boston's per-capita allocation of $4.60 trails Cambridge's $17.10 and Somerville's $12.50, a gap advocates are actively pushing to close. Los Angeles ran its L.A. REPAIR pilot across nine neighborhoods with roughly $8.5 million distributed. Denver's first cycle put $2 million toward neighborhood infrastructure. Sacramento approved up to $1 million in Measure U funds for resident-directed spending, and Philadelphia set aside $1 million for capital projects.
Across all of these, a pattern holds. Funding pools range from under $1 million to tens of millions, and eligibility usually extends past citizenship and age requirements typical of regular elections, often including non-citizen residents and kids as young as 11. And every serious program now runs multiple submission channels at once: online, phone, and in-person.
The four stages every PB process must support and why each one creates a software requirement
Every PB cycle, regardless of city, moves through the same basic stages, and each one puts a different demand on the software behind it.
Idea collection comes first. Residents submit raw proposals, often in free text, and the platform needs to handle categorization and multiple languages right out of the gate. Then comes deliberation: proposals get discussed, sometimes merged with similar ideas, and shaped into something that could actually be built. This stage needs forum-style tools and someone moderating the conversation, because open comment sections without moderation tend to go sideways fast.
Feasibility review is where government staff step in, checking cost, legal permissibility, and technical viability before anything reaches a ballot. The software here has to support staff workflows and let everyone track a proposal's status. Voting follows, and this is the stage most people picture when they hear "participatory budgeting": residents cast ballots, sometimes choosing individual projects, sometimes working within a fixed budget constraint, and the platform needs to authenticate voters, offer multilingual ballots, and support both online and in-person modes at once.
Then there's reporting: publishing results, and ideally tracking winning projects all the way through construction or implementation. This is where most platforms fall short, a point worth sitting with, because it's also where a resident's trust in the whole process either holds or breaks.
Each stage fails in its own particular way if the software can't keep up. Weak idea collection tools mean low submission volume, and clunky voting access means the electorate skews toward whoever finds it easiest to participate, which usually isn't the population PB is meant to reach. And thin reporting means no one can tell if any of it mattered. Boston's approach, running an online portal alongside a phone line, library branches, and community events, makes a point worth remembering: no single digital tool reaches the whole population, so software has to work alongside offline outreach.
Decidim: the open-source platform most widely deployed for PB in U.S. and global cities
Decidim is an open-source platform built to let cities configure participatory processes, budgeting among them, without coding one from the ground up. It also handles consultations, citizen initiatives, referendums, and assembly governance, and it's modular by design: a city turns on the pieces it needs (proposals, voting, meeting records, results publishing) and sets its own rules for each.
The scale is worth noting. As of December 2024, Decidim counted 1,988,415 registered users, 75,885 proposals created, and 286 active processes running globally. New York City runs on it, and the New York deployment is what makes it most visible to U.S. audiences.
For PB specifically, Decidim covers multilingual support, meeting documentation, and full lifecycle tracking of a proposal from the moment it's submitted through the vote and into results. The catch with open-source software is that being free to use doesn't mean it's free to run. Cities can fork it and customize it however they like, but deploying it takes real technical capacity, and smaller cities without an in-house engineering team usually end up bringing in a vendor or consultant to get it live. Decidim itself is maintained by an open collective, so cities that adopt it are, in a sense, contributing back to shared civic infrastructure rather than paying a licensing fee year after year.
CONSUL Democracy: the other major open-source platform and how it handles the full PB workflow
CONSUL Democracy is the other big open-source option, and it casts a wider net than Decidim's default setup. It covers proposals, participatory budgets, public consultations, and collaborative legislation, which puts it closer to a full civic participation suite than a tool built around budgeting alone.
CONSUL has been adopted by institutions across multiple continents, in cities ranging from small towns to major metros. Its multilingual support matters a great deal for cities with large populations who don't speak English as a first language.
The feature that sets CONSUL apart is its collaborative legislation module. Instead of just choosing among pre-vetted spending options, residents can co-draft language that resembles actual policy text. That's a step past a typical PB ballot; it edges toward citizens shaping the law itself, not just the line item. Like Decidim, CONSUL is free to fork, and the same constraint applies: cities adapt it rather than subscribe to it, and adapting it takes technical staff. Any city sizing up CONSUL can look to well-documented, high-volume municipal deployments as a track record, not just a demo.
How U.S. cities actually configure and supplement these platforms in practice
Almost no city runs one of these platforms straight out of the box. They configure it, customize it, and build extra tools around the edges.
New York's two-track setup shows this clearly. PBNYC and The People's Money sit on different administrative structures within the same city government, which means the software has to serve council staff, the Civic Engagement Commission, and community partner organizations all at once, none of whom report to the same office. Offering ballots in 13 languages, as The People's Money did, takes deliberate configuration work, language by language.
The hybrid voting design tells a similar story. In the 2023-24 NYC cycle, over 31,000 people voted online, and a bigger share voted on paper at physical sites, which means the platform has to export ballot formats that work for in-person tabulation, not just serve the digital voter and call it done.
Some of the most important infrastructure isn't software at all. New York's $1.7 million investment in 93 community organizations to reach equity neighborhoods in 2022-23 is a human layer, funded separately, that no platform generates on its own. Boston's redundant intake channels, online portal, phone line, library branches, city hall, community events, work the same way: the software covers the digital lane, and everything else needs a person doing manual intake and typing results in by hand.
Feasibility review shows a similar seam. The platform can track a proposal's status as it moves through staff review, but the actual assessment (costing a project out, checking legal permissibility, confirming site control) happens inside city departments, often on systems that don't talk to the civic engagement platform at all. And NYC's Borough Assemblies in the 2024-25 cycle, where randomly selected residents helped shape the ballot, needed facilitation tools, documentation, and deliberation records that go beyond anything a voting platform alone provides.
Where the current software stack leaves PB processes incomplete
The most consistent gap sits after the vote. Platforms are generally good at handling everything from submission through the ballot; they're much weaker at telling a resident, six months or two years later, whether the project they voted for actually got built. That silence costs trust, and it's arguably the single biggest weakness in the current software stack.
There's also a real tension in how these platforms handle voter identity. Strict verification risks locking out exactly the residents PB is meant to reach: undocumented residents, younger participants, people without a government-issued digital ID. Loose verification, meanwhile, opens the door to manipulated results. Most platforms split the difference with geographic attestation or some form of community vouching rather than full identity verification, which is a reasonable compromise, though not a perfect one.
Funding gaps between cities, like Boston's $4.60 per capita against Cambridge's $17.10 and Somerville's $12.50, reflect a political allocation choice, one software doesn't create or fix on its own. What software can do is make the gap visible: a public dashboard showing per-capita spending across comparable cities creates a kind of pressure that a closed spreadsheet never will.
Feasibility literacy is another soft spot. Residents submitting ideas often don't know what's legally possible or technically realistic for a given budget, and most platforms collect the proposal without helping the resident understand why it got rejected or how to fix it and resubmit. That's a missed opportunity, not a hard technical problem.
And then there's the capacity issue. Both Decidim and CONSUL are free to use, but deploying either one takes real engineering work. Smaller cities that want to run PB but don't have that staff on hand often end up leaning on consultants, or settling for a simpler, less capable tool. Digital-first platforms, even multilingual ones, also tend to underrepresent older and lower-income residents by default; the paper-ballot infrastructure that New York maintains alongside its online voting is expensive, and hard for a smaller city to replicate at the same scale. One more thing worth flagging: CONSUL's collaborative legislation module points toward something bigger than budgeting, residents co-drafting actual policy text, but most U.S. cities only use the budgeting piece. That capacity sits there, mostly untapped.
What makes a PB vote feel legitimate to residents — and what the software must get right to earn that trust
Legitimacy in PB isn't just a matter of following the right steps in the right order. It's relational: a resident has to believe their vote actually changed something, and that belief depends on follow-through no platform can manufacture by itself.
Software can carry real weight here, though. A transparent idea lifecycle, where a resident can watch their own proposal move from submission to review to ballot to result, builds confidence on its own. Accessible voting, meaning multilingual ballots, multiple channels, and low-friction authentication, widens who actually gets to take part. Publishing results quickly and in a format regular people can read, not a buried PDF, matters more than it sounds like it should. And linking a winning project to its actual budget line, then tracking it through to completion, closes the loop that too many cities leave open.
But there's a limit to what code can do. Political will to hand over meaningful money is something no platform can supply; Vallejo and Chicago's programs worked, in part, because officials actually gave up authority, not just the appearance of it. The community partner network needed to reach residents who've historically been shut out is something no platform builds on its own, which is exactly why New York put $1.7 million into 93 organizations rather than assuming the app would handle it. And the staff work of reviewing a proposal honestly and explaining, in plain terms, why it didn't make the cut, is something no platform does either.
Which raises the real question underneath all of this: is software even the right lever for the parts of PB that are still broken? Decidim and CONSUL come closest to answering yes, precisely because they were built as civic infrastructure from the start, not bolted-on engagement features. The next frontier sits past where either platform currently goes: turning a funded PB project into something with the durability of formal policy, a resolution, an ordinance, a real capital commitment. That's a different kind of civic tool than a budgeting platform, one built to route citizen-drafted proposals straight to elected officials with verified community backing behind them. PB got residents a vote, and the next layer of this stack has to get them a law.


