Decidim participatory budgeting implementation: what a city team must decide first
A city, county or other public body that wants residents to allocate part of a budget through Decidim runs that process with the budgets component. The work is not the software install. It is configuration, verification and data: setting up the budget and its projects, defining how votes are cast and counted, deciding who may vote, and publishing results that residents can check. Each of these needs an owner inside the organization before a partner or internal team configures anything. Decidim is a free, open-source participatory democracy framework licensed under the AGPL-3.0. It is built on Ruby on Rails and PostgreSQL and provides participatory spaces such as processes, assemblies and initiatives, along with components that include participatory budgets, proposals, meetings and surveys. Because the platform is modular, many teams run participatory budgeting in the same period as other participation processes, such as proposal collection or assemblies. Those processes share users, spaces, permissions and the same public site, so their timelines and content rules have to be planned together.
The first decisions are about the budget itself. Teams need to settle the total amount that residents will allocate, how it is divided across districts or thematic areas, what counts as an eligible project, and who writes, costs and checks each project before it reaches the ballot. Teams also need to decide the voting method and the rules for ties and minimum project costs, since the component will enforce whatever rules are configured. Project data, such as descriptions, locations and cost estimates, should be cleaned and approved before import, because residents will judge the process by the quality of what they see.
A second group of decisions concerns trust. The organization must choose how votes are linked to verified residents, which authorization methods are acceptable for its legal context, and whether results must be reproducible by outside observers. It must also decide what is published during and after voting, and who can correct errors. Hosting is part of the same decision: the build runs in infrastructure the organization controls, so the team must confirm who operates the servers, backups, email and file storage, and who is accountable for them. The sections that follow take these decisions in turn, with the checks and data work each one requires.
What the Decidim budgets component does
Decidim treats participatory budgeting as one component inside a participatory space, so budgets sit alongside proposals, meetings and other tools in the same process. The cards below cover what the budgets component holds, how it connects to neighboring components, how verification gates voting, and how results are followed after delivery.
Budgets and their projects
The budgets component organizes funding into budgets, and each budget holds the projects residents can support. A budget carries its own total amount and its own set of projects, so one participatory space can run more than one budget. Before launch, confirm in the current Decidim documentation for your version how budgets and projects are created, edited and published, and which fields are required for each project.
Components within a participatory space
Decidim places the budgets component inside a participatory space such as a process or assembly, next to components like proposals and meetings. This matters because residents often submit ideas as proposals, discuss them in meetings, and then see the best ones become budget projects. Map which components the space needs and confirm how projects link back to proposals in the version you run.
Vote rules and phase settings
Voting behavior is controlled through component settings, including how many votes or how much budget a participant can allocate and when voting is open. The exact setting names, vote rules and phase options change between releases, so check each one against the Decidim docs for the version in use. Document the rules you choose before launch, since changing them mid-vote affects fairness and support requests.
Verification gates on voting
Decidim includes identity verification and authorization so an organization can limit actions such as voting to verified participants. Decide which verification method residents must complete before they can vote on budget projects, and test that unverified users are blocked. Confirm the authorization options available in your version and how they are configured for the budgets component.
Accountability after delivery
Decidim also provides accountability tracking, which lets an organization report on funded projects after they are delivered. This turns a vote into a public record of progress and outcomes. Plan who updates project status, what statuses and evidence are shown to residents, and how often updates are published, and confirm the accountability options in the docs for your version.
Results and audit trail
Once voting closes, the results need to be published in a way residents and auditors can check. Decide which results are public, how ties and excluded projects are shown, and how the vote record is retained. Confirm in the Decidim documentation how results are exposed for your version, and export a test set to verify totals before publication.
Which budget and voting decisions shape the build
This table compares the configuration decisions that set how a Decidim participatory budget works for residents and staff. Read each row as a decision to settle in writing before the build starts, since most of them change what the platform must be configured to do. The main takeaway is that voter eligibility and vote visibility carry the most governance weight, so the approving body should agree on them first.
| Decision | Options | What changes for residents and staff | When it fits |
|---|---|---|---|
| Budget size and currency | One budget for the whole process, or several budgets (for example per district or theme) | Residents compare projects only within the budget they can vote on. Staff must confirm the total and currency before launch. | One budget fits a single citywide pot. Several budgets fit areas that fund separately. |
| Project grouping | Flat project list, or projects grouped by district, theme or category | Grouping changes how residents filter and compare. Staff maintain group labels and check that each project sits in one group. | Flat lists fit small processes. Groups fit large project pools covering many subjects. |
| Project eligibility | Open to all proposals, limited by location, or limited by category or type of project | Staff screen proposals against the rules. Residents see only eligible projects and need clear reasons for any exclusion. | Open rules fit broad calls. Location limits fit neighborhood budgets. Publish the rules before proposals open. |
| Voter eligibility | Any registered user, or only verified participants using Decidim's authorization workflows | Verification limits who can vote but adds a step residents must complete. Staff run checks and handle appeals. | Verified voting fits binding public budgets. Open voting fits advisory exercises with lower stakes. |
| Voting rules | Per-person limit on the number of projects or amount, or allocation of points across projects | The rule shapes how many choices each resident makes. Staff define the rule and confirm it matches the budget text. | Per-person limits fit simple choices. Point allocation fits residents ranking priorities. Confirm exact options in your version. |
| Vote visibility | Individual votes hidden from other users with totals published, or individual votes visible | Visibility changes trust and the chance of public pressure. Confirm what administrators can see in your version. | Hidden individual votes fit sensitive topics. Decide with legal counsel and your governance policy. |
| Results format | Funded project list, full ranked results, or full vote counts with tie and cutoff handling | Residents see outcomes in different levels of detail. Staff must agree tie and cutoff handling before voting opens. | A funded list fits short public reports. Full counts fit processes that need external scrutiny. |
How Decidim participatory budgeting ties each vote to a verified resident
Decidim can restrict voting in a participatory budget to verified participants, so the result reflects residents and not simply anyone with an account. Two steps are involved and they should be designed separately. Identity verification establishes who is signing in. Authorization decides whether that person may vote in this specific budget. Before the build starts, write down the eligibility rule for voting: who qualifies, what evidence proves it, and what happens to someone who cannot prove it. Then confirm with your team which authorization handlers are available in the version you plan to run, because the set of handlers can differ between releases and any handler you need beyond those will require custom development.
The verification method is the most consequential decision in this part of the build. The common options are an existing identity provider that already holds residency data, a registry lookup against a civil or municipal register, and a postal code check. An identity provider is quick to integrate but is only as accurate as the records behind it. A registry lookup gives the strongest evidence but needs data access agreements, a legal basis for the check, and an integration that someone must maintain. A postal code check is simple, but a postal code can cover people outside the eligible area and can be mistyped or misreported. For each option, ask the vendor and your own integration team which handler is native to the planned version and which would need to be built.
Strict eligibility and resident access pull in opposite directions. Stricter checks reduce duplicate votes and votes from non-residents, but they also exclude residents who lack the documents, digital skills or willingness to share personal data that the check requires. Decide the fallback before launch. Common options include assisted verification at a public counter, a paper or offline route with a documented manual check, or a lower-friction method for a defined group. Illustrative example: a council that requires a registry match may see more drop-off than one that accepts a postal code, so the support desk and the pilot plan should be sized for the stricter route. Measure the drop-off during a pilot and adjust the rule with the decision owners before the voting window opens.
Social login needs careful framing. Decidim supports Facebook, Twitter, Google and Decidim-to-Decidim OAuth 2.0 login out of the box, and these can be configured globally or per organization. These providers confirm that someone controls an account. They do not confirm that the person lives in the eligible area, so most public budgets should use them only for sign-in and attach a separate authorization step for voting. If your organization needs to connect a national or regional identity provider, Decidim allows custom OmniAuth strategies to be added. That work includes testing the callback flow, mapping the attributes you receive, and completing a data protection review of what is stored. Confirm which providers your target version includes and whether each can be disabled for a single organization.
Implementation sequence for a Decidim participatory budgeting rollout
This sequence takes a Decidim instance from version selection to a participatory budgeting module that your operations team can run without us. Each step closes with a named output, so you can confirm what is complete before the next step begins.
Confirm the Decidim version and hosting
Choose the branch before any other work, because it sets the runtime. Version 0.32 requires Ruby 3.4.7 and Node 22.14.x, while 0.31 uses Ruby 3.3.4 and Node 22.14.x, so the build images and servers must match the branch you select. Only the 0.32 and 0.31 branches receive security updates, which makes them the starting points to consider. Agree the hosting model with your team, either a manual Rails installation or Docker, in cloud accounts or data centers you control. Record the PostgreSQL target, which the manual guide lists as 17.4 or later on Ubuntu 24.04.3 LTS. Output: a signed version decision record and an environment sheet naming runtimes, hosts and owners.
Install and configure the production stack
Install the application and configure the production services it depends on. This covers background jobs through ActiveJob, file storage through ActiveStorage, outbound email through SMTP, and maps and geocoding for project locations. Decide which social login providers residents will see. Decidim supports Facebook, Twitter, Google and Decidim-to-Decidim OAuth 2.0 out of the box, configurable globally or per organization, and other OmniAuth strategies can be added as custom providers. Test each service with a smoke test before any staff account is created. Output: a configured production environment with a smoke-test log and a list of enabled login providers.
Configure identity verification before voting opens
Set up the verification and authorization workflows that restrict voting to verified participants. Decidim includes flexible identity verification, so the method must reflect your own eligibility rules, such as residency or age checks, and your data protection requirements. Confirm with your legal or election team exactly who may vote and what evidence the system needs to record. Test accepted, rejected and expired verification paths using test accounts, and confirm that unverified users cannot cast a vote. Output: a documented authorization configuration and a test report covering each verification outcome.
Create the budget and project structure
Build the participatory space, the budget and its projects in the budgets component. Enter project categories, geographic areas, cost figures and descriptions in a staging copy, then check each project against the source inventory supplied by the city or organization. Define the voting rules, including minimum and maximum selections, the amount allowed per budget, and how ties and partial funding are handled, using the options the installed version exposes. Have the budget owner review the rules in writing. Output: a signed-off voting rule set and a reconciled project inventory.
Test voting end to end
Run the full voting path with a small group of staff first, then with pilot residents who represent the eligible population. Scenarios should include verified and unverified users, selections at the limits, changes before the deadline, attempts to vote after close, and the handling of projects that go over budget. Log every defect with its reproduction steps, fix it in staging, and retest the affected scenario. Check the emails and notifications that participants receive. Output: a test report listing scenarios, results, defects and the retest outcome, with a go or no-go recommendation for launch.
Publish results and close the cycle
Publish the voting results and project outcomes once the voting period closes and the counts are checked against an independent export. Confirm that the published pages show the correct budget totals, winning projects and status for each project. Take a database backup before any change to the production data, so the state of the cycle can be restored if a correction is needed. Record the publication date, the reviewer and the export used. Output: published results, an archived copy of the vote export and a sign-off record from the budget owner.
Hand over the runbook and operations
Transfer ownership to your operations team with a runbook covering backups, restore tests, monitoring, the admin procedures used during the cycle, and access control. Include the Decidim update guidance: upgrade one minor version at a time, follow each release's upgrade instructions because some change database structures, and back up the database first. Walk the team through a live admin session and confirm who holds each credential. Output: a runbook, a recorded training session, and a named support contact list agreed with your team.
Migrating existing budget data into Decidim
Start the migration with a data inventory before any import script is written. Most teams bring over five kinds of material from a previous process: past budgets, project descriptions, supporting documents, vote totals and the resident records used to decide who was eligible to vote. Each kind needs an owner, a source system, a format and a decision about whether it moves at all. Resident records need the most care. They are personal data, and copying them into a new system widens the group who can access them. For each record set, decide whether Decidim should hold it, whether eligibility should be re-established through the platform's identity verification and authorization so that only verified participants can vote, or whether the records should stay in the source system with only an aggregate count carried over. Record each decision in writing before any data is touched.
Data moves into Decidim through controlled imports or scripts that write to the platform's database. Decidim is built on Ruby on Rails and PostgreSQL, so the import should go through the application's own import options or a script that uses its data models. Direct edits to database tables bypass the checks the application relies on. The import options depend on the Decidim version you run. Decidim currently supports the 0.32.x and 0.31.x lines with security updates, and the installation guides differ by line, including the Ruby version and the database release. The manual installation guide names PostgreSQL 17.4 or later on Ubuntu 24.04.3 LTS. Confirm the import tooling, supported field formats and attachment handling with the Decidim documentation for your exact version before writing any field mapping. In production setups, attachments are stored through ActiveStorage, so file transfer and storage configuration must be planned alongside the database work.
Keep old results as archived records. Do not edit a past budget's totals, project outcomes or vote counts to fit the new structure. An edited result is hard to defend when a resident or auditor compares it with the published original. Load each past cycle as a read-only record that carries its source system, export date, the rules that applied at the time and a row count or checksum from the export. If the new budget reuses project titles or categories, map them in a separate reference table so the original wording is preserved. Agree with the communications and legal owners how archived results will be labeled on the public site. Then confirm with the Decidim documentation how the platform presents imported or historical results, so the labels do not suggest a live vote is still open.
Run a test migration on a copy of the production database before any live data moves. Restore a recent backup into a staging environment that runs the same Decidim version, PostgreSQL major release and storage configuration as production, then run the full import. Check record counts for budgets, projects, documents and votes against the source export, spot-check individual projects and totals, and confirm that attachments open. Repeat the run until the counts match and the steps are scripted and repeatable. Time each run so the cutover plan reflects measured results. Also rehearse the rollback. If the migration includes a version upgrade, Decidim's update guide asks you to move one minor version at a time, follow each release's upgrade instructions and back up the database first, because some releases change database structures.
What drives Decidim participatory budgeting implementation effort
This table lists the factors that change the size of a Decidim participatory budgeting project, why each one matters, who carries the cost and how to keep it under control. Read it before requesting a quote, because client staff time and hosting decisions often affect the schedule as much as the build itself.
| Driver | Why it changes the work | Who pays and one-time or recurring | How to keep it down |
|---|---|---|---|
| Number of budgets and projects | Each budget needs its own amounts, categories, project records and images, and each project needs review before voting opens. | Client staff enter or approve content (one-time per cycle). Partner configures and tests the setup (one-time). | Limit the first cycle to what your staff can review, and reuse templates for later cycles. |
| Complexity of voting rules | Vote caps, minimum and maximum project counts and spending ceilings each need configuration and test cases. Confirm which rules your version supports natively. | Client policy owners decide the rules (one-time). Partner configures and tests each rule (one-time). | Agree the full rule set in writing before the build, and avoid rules that depend on custom code. |
| Number of verification methods | Decidim includes identity verification so voting can be limited to verified participants. Each added method adds a flow, a data source and support questions. | Client pays any external verification service (recurring). Partner configures and tests each flow (one-time). | Start with one method, and add others only after the first cycle runs cleanly. |
| Data migration volume | Imported participants, past results and proposals each need mapping, cleaning and reconciliation. Data quality changes the work more than record count alone. | Client staff provide and validate source data (one-time). Partner builds and runs import scripts and checks (one-time). | Define which historical data is needed, clean it at the source, and rehearse imports on a copy. |
| Number of languages and locale-prefixed URLs | Each language needs translated interface text, budget content and checks on locale-prefixed URLs, including links and redirects. Decidim v0.32 uses locale-prefixed URLs. | Client translators and reviewers pay for translation (one-time, then per content change). Partner tests locale routing (one-time). | Limit launch languages, and add translation time for new content to the cycle calendar. |
| Accessibility review | The ADA Title II rule requires WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people. Confirm your entity's date. | Client pays for an independent audit if its policy requires one (one-time). Partner fixes configuration and theme issues found (one-time), then re-tests after changes (recurring). | Review templates and theme choices early, and test the voting pages before launch. |
| Hosting model | Self-hosting makes you own patching, backups, monitoring and capacity for the database, background jobs, file storage and SMTP. | Client pays infrastructure and operations staff (recurring). The Decidim software carries no license fee. | Document the target environment first, and choose manual or Docker installation to match your operating standards. |
| Integrations with email, maps and identity providers | Each email relay, maps and geocoding service and login provider needs configuration, credentials and testing. Providers beyond the built-in set need custom OmniAuth work. | Client supplies accounts and credentials (one-time, with recurring renewals). Partner configures and tests each integration (one-time). | Reuse your existing identity provider and mail relay, and offer only the login options residents need. |
| Version upgrades | Upgrades move one minor version at a time, and some change database structure. Only the last two minor versions receive security updates before version 1.0. | Client approves upgrade windows and backups (recurring). Partner plans and tests each upgrade (recurring if retained, otherwise scoped separately). | Budget upgrades into your operating plan, back up the database before each step, and keep a current test environment. |
How participatory budgeting connects to identity, email and maps
A participatory budget depends on more than the budgets component. Identity, verification, email, background jobs, file storage and maps run as separate services that Decidim calls during sign-in, voting, notices and project publishing. Confirm each connection with your own systems and the Decidim configuration documentation before you scope the work.
Identity and social login
Residents sign in through the accounts Decidim is configured to accept. Decidim supports Facebook, Twitter, Google and Decidim-to-Decidim OAuth 2.0 out of the box, configurable globally or per organization, and other OmniAuth strategies can be added as custom providers. Decide which providers residents may use, whether your existing identity provider or a staff directory is the source of truth, and whether social logins are acceptable for votes at all. Confirm each provider's setup against the social providers section of the Decidim documentation.
Verification and authorization
Decidim includes identity verification and authorization systems that let an organization restrict actions such as voting to verified participants. This layer is what ties a budget vote to a verified resident. Map which verification method your process requires, which vote rules apply to each budget, and how the same verification is reused by the citizen initiatives module, which runs as a sibling process and shares identity and verification. Confirm the workflow with the owners of your registry or civil data before scoping.
SMTP for confirmations and notices
Account confirmations and notification emails sent during a budget process leave Decidim through SMTP. Confirm the sending domain, authentication method, DNS records and any rate limits of your mail provider with your mail team. Plan for bounces and for residents with outdated addresses, because a missing confirmation can block sign-up or voting. Test messages in every locale your organization publishes before launch, and confirm the settings against the Decidim installation guide.
ActiveJob workers for background tasks
Decidim hands queued work such as sending notifications and other deferred tasks to ActiveJob, so production setups need a configured queue backend and running workers. Decide where workers run, how many you need for the traffic expected during a voting window, and how failed jobs are retried and monitored. Ask your team which queue adapter fits your infrastructure, and confirm whether worker setup and monitoring are included in the written scope. Verify the setup against the Decidim installation documentation.
ActiveStorage for project attachments
Project pages often carry attachments such as cost estimates, supporting documents and photos. ActiveStorage handles these files, so the storage service you configure determines where uploads live. Decide on the storage backend inside your infrastructure, retention rules, file size and type limits, and how uploads are checked before publication. Include attachments in your backup plan alongside the PostgreSQL database, because restoring one without the other leaves broken references. Confirm the storage configuration in the Decidim installation documentation.
Maps and geocoding for project locations
Projects that refer to a neighborhood, street or facility need a map and a geocoding service to place them. Choose the map tile provider and geocoder, review their terms for public use and data handling, and decide whether to use an external service or one hosted inside your network. Confirm which location fields residents see, how precise coordinates must be, and what happens when an address cannot be resolved. Check the configuration against the Decidim installation documentation and your privacy team's requirements.
Publishing results and meeting accessibility obligations
Decide when results go public before voting opens, because the publication date determines when residents can question the outcome and when your team must be ready to answer. Most teams publish only after votes are closed, counted and checked, and they post a dated notice that names the tallying step. Next, decide the level of detail for each project: title, summary, estimated cost, location or district, status (funded, not funded or withdrawn), and the reason for any change from the proposed amount. Residents judge fairness from this record, so every field should come from one approved source. Write the publication decisions as a matrix, signed off by the clerk or budget office, before the first project is created in the budgets component.
Next, decide how vote data appears. The options range from publishing only the funded projects, to showing vote totals per project, to breakdowns by district or age band. Each added breakdown raises the chance that a small group of residents can be identified, so review every cut with your privacy officer before the results page goes live. Confirm in your Decidim version which vote figures the budgets component exposes publicly and which remain visible only to administrators. Test the public view with an account that has no admin role. Also decide whether voting data exports, such as CSV files, are published, restricted or withheld. Verification records tied to individual residents should never appear in any public export.
For public bodies, accessibility belongs in the publication plan from the start. The ADA Title II rule requires state and local government web content, including content provided through contracts or licenses, to meet WCAG 2.1 Level A and AA. The compliance date is 26 April 2027 for entities serving 50,000 or more people, and 26 April 2028 for smaller entities and special districts. Check which date applies to your entity. Then confirm with counsel whether the results pages, embedded charts and documents on a Decidim site you operate or license fall within that scope. DeployOpen does not issue accessibility certifications or audit reports. An independent accessibility auditor will assess conformance, and counsel should confirm the legal position.
Build accessibility checks into the publication workflow. Test results pages with keyboard navigation, a screen reader and sufficient color contrast. Confirm that every vote chart has a text equivalent that carries the same figures as the table beside it. Check any PDF or CSV published with the results, because documents are a common source of conformance gaps. Keep test records for each release so the auditor can trace what was checked and when. Decidim supports only its last two minor versions with security updates, currently 0.32.x and 0.31.x. Confirm in the release notes whether accessibility fixes reach those branches, and schedule any required upgrade before the results period opens. Agree the target version in writing with your implementation partner.
Questions teams ask before implementing Decidim participatory budgeting
How much does a Decidim participatory budgeting implementation cost?
A quote follows from the written scope, and DeployOpen does not publish a price list. The main cost drivers are the number of budgets and their rules, the number of projects and categories in each budget, the verification design that decides who may vote, any data migration from an existing process or platform, and the hosting environment, whether that is your cloud account, your data center or an air-gapped network. Ask each bidder to price these items separately so you can see which choices move the total. One-time costs cover scoping, configuration, customization, integration, testing and launch. Recurring costs cover hosting, Decidim upgrades and any support retainer, which is optional and set out in writing.
How long does a Decidim participatory budgeting implementation take?
The duration depends on the written scope, so ask for a timeline in the proposal rather than relying on a general estimate. The factors that lengthen the work are the number of budgets running in parallel, complex voting or eligibility rules, the link between verification and resident records, historical projects that must be migrated, and how quickly your staff can review test cases and sign off decisions. Expect a test cycle with your real voting rules, a review of how results will be published, and a launch date set around your budget calendar. Confirm which milestones depend on your reviews and data deliveries, because those dependencies often decide the schedule.
What does our team need to provide before implementation starts?
Your team provides the decisions and access that only your organization can give. That includes the budget rules (who proposes, who is eligible, how votes are counted, minimum and maximum amounts and tie-break logic), the project lists with descriptions, costs and eligibility notes, and a named decision-maker for each approval. You also need staff who can test the voting workflow end to end and confirm results, a list of verification data sources and the legal basis for using them, and access to the hosting environment and identity systems that will be connected. Agree on who owns communications with residents before the first test.
Which costs recur after a Decidim budget goes live?
Recurring costs continue after launch and should be budgeted as an annual operating line. Hosting in your own infrastructure is the first, including compute, database, file storage, email delivery and backups. Decidim upgrades are the second, because each supported minor version has its own upgrade steps and database changes. Security patching is the third, since Decidim gives implementers a defined window to apply patches before vulnerability details are disclosed. A support retainer is optional and covers ongoing help, upgrades and testing under a written agreement. If your verification relies on a paid external provider, that provider's fees recur as well, and their terms set the amount.
Can our in-house team build Decidim participatory budgeting alone?
An in-house team can run the build if it already has Ruby on Rails and PostgreSQL operations skills, a staging environment, capacity for testing, and an owner for upgrades. Decidim is free software under the AGPL-3.0, so the main costs are people, hosting and integration work rather than a software license. The risks are the parts that are easy to underestimate: configuring budget rules correctly, connecting verification to your data sources, running a voting test that matches a live cycle, and keeping the platform on a supported version. Decide early which of these your team will own, and whether a partner will cover any of them under a fixed-scope agreement.
Which Decidim version should we install for a new budgeting project?
Install a version that still receives security updates. Until version 1.0, Decidim supports only the last two minor versions, which are currently 0.32.x and 0.31.x, so 0.30.x and earlier should not be used for a new project. Decidim v0.32.1 was released on July 30, 2026, and v0.32 requires Ruby 3.4.7 and Node 22.14.x, while v0.31 uses Ruby 3.3.4 and Node 22.14.x. The manual installation guide uses PostgreSQL 17.4 or later on Ubuntu 24.04.3 LTS. Check the Decidim releases page on the day you start, because newer patch releases may have been published since this page was written.
How do we tie budget votes to verified residents in Decidim?
Decidim includes identity verification and authorization features that let an organization restrict actions such as voting to verified participants. The design work is deciding which verification methods your organization can legally and practically use, which records confirm eligibility, and how those checks map to each budget's rules. Confirm with your data protection officer and legal team which data sources can be used and how long verification records are kept. Ask your implementer to show a test where an unverified account is blocked from voting and a verified account can vote once. Document the workflow so auditors and staff can see how a vote was authorized.
Should we plan Decidim upgrades before the first budgeting cycle?
Yes, plan upgrades before the first cycle, because they affect when you can safely change the platform. Decidim's update guidance says to upgrade one minor version at a time, for example 0.29 to 0.30 before 0.31, and to follow the upgrade instructions for each release because some changes alter database structures. Back up the database before every upgrade and test the restore, not only the backup job. Schedule upgrades outside active voting periods and confirm the rollback steps in writing. Include the upgrade path in your recurring cost plan so the budgeting team is not left running an unsupported version during its next cycle.
How DeployOpen scopes and delivers Decidim participatory budgeting
DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Decidim participatory budgeting, we agree the budgets, projects, voting rules and verification design in writing before build work starts, then deliver and document the configured component in your infrastructure.
How we scope
- Engagements are fixed-scope, with the budgets, projects, voting rules and deliverables agreed in writing before work starts.
- The written scope should name each budget, its voting phases, the project data fields and the results pages to be published.
- Scoping records which residents may vote, which verification methods apply and how those checks connect to the budgets component.
How we build
- We install Decidim in your environment, configuring PostgreSQL, background jobs, file storage, SMTP, maps and geocoding for production.
- We configure the budgets component, sample projects and voting workflows, then test each phase against the agreed rules.
- We test identity verification and authorization so only verified participants can cast votes, and we record the results of each test.
How we hand over
- Handover includes configuration records, runbooks for opening and closing voting, and the verification settings in use.
- Operators receive instructions for publishing results and for correcting project data during and after a voting period.
- Backup and restore steps for the database and uploaded files are documented and demonstrated before go-live.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrades follow Decidim's guidance to move one minor version at a time, with a database backup taken first.
- Confirm with DeployOpen which Decidim versions are supported at the time of your engagement and plan upgrades around election calendars.
