Decidim cost of ownership

What does a Decidim platform cost to own when the software is free?

Decidim carries no license fee because it is licensed under the AGPL-3.0, so the cost of ownership is the infrastructure, labor, services and internal skills around it. A cost review usually starts in one of three situations: a new participation platform is being planned, a commercial engagement SaaS contract is up for renewal, or an organization is considering moving an existing platform to self-hosting. The short answer most organizations reach is that they pay for hosting and recurring operations themselves, and bring in a partner for the initial build, upgrades and specialist work. The sections below set out which costs recur and what to ask for in a quote.

Hosting and operations are the first recurring lines. Decidim runs as a Ruby on Rails application on PostgreSQL, and a production setup also needs background jobs (ActiveJob), file storage (ActiveStorage), SMTP, maps and geocoding, and any social login providers you enable. Each of these is a service that someone runs or pays for: compute, database hosting and backups, file storage, outbound mail, and map or geocoding services. Confirm with your cloud or data center team which items are metered, which are fixed, and who owns the backup retention policy. Ask any partner to itemize these as recurring lines, separate from build work, so the monthly or annual run cost is visible before you compare it with a SaaS subscription.

Labor and internal skills are the second recurring cost, and they are easy to underestimate. Someone on your team needs working knowledge of Ruby, Rails, Node and PostgreSQL to keep the platform healthy, and someone must own the security side. Decidim supports only the last two minor versions with security updates, currently 0.32.x and 0.31.x, and it gives implementers a grace period of 2 months for standard vulnerabilities and 4 months for critical ones before details are disclosed. Each minor upgrade must be done one minor version at a time, following that release's instructions, with a database backup first. Ask how many upgrade cycles your team must absorb in a year by checking the release history against your support window, and decide whether that work stays in-house or sits under a retainer.

Custom work is where one-time costs often grow. Decidim includes authorization handlers so you can restrict actions such as voting or signing to verified participants, and the verification method you choose drives effort. Facebook, Twitter, Google and Decidim-to-Decidim OAuth 2.0 logins are available out of the box and configurable globally or per organization, while a national eID or an internal identity provider usually requires a custom OmniAuth strategy. Each custom module, login provider or verification rule also has to be retested after every upgrade. Confirm with your governance and legal teams which login methods and verification rules are required before the build starts, because changes after launch recur as testing and redevelopment work.

A SaaS quote bundles hosting, upgrades and support into one subscription, so comparing it with self-hosting means building a like-for-like list. For the self-hosted option, separate one-time items (initial build, branding, custom modules, data migration and launch) from recurring items (hosting, backups, storage, mail, upgrades, security patch handling and incident response). Ask any implementation partner for a written scope that names each item, the assumptions behind it, and the responsibilities split between your team and theirs. Also ask the SaaS vendor what it charges for custom modules, extra storage and data export at the end of the contract. A comparison built on these lines shows where the costs of ownership actually sit, which a headline subscription figure does not.

Which cost categories does a Decidim cost of ownership review cover?

A Decidim cost of ownership review sorts every cost into categories so each one has a named payer and a clear pattern of one-time or recurring spend. The cards below follow those categories. Internal staff time runs through all of them and is easy to leave out of a budget. A complete review returns a cost model, an assumptions register and an annual calendar of upgrade and patch work.

Hosting and environments

Infrastructure the client pays for each month or year: application servers, PostgreSQL, file storage, background job workers, SMTP relay, and map or geocoding services. Most Decidim instances need a staging environment in addition to production so upgrades can be tested before participants see them. Ask whether the quote lists provisioning, backups and monitoring as separate lines, and confirm which parts run in the client's own cloud account or data center.

Implementation and custom modules

One-time work to install, configure and brand the platform, plus any custom components, themes or OmniAuth providers the organization needs beyond the standard set. Custom code adds recurring cost because each minor upgrade must be retested against it. Ask the partner to list every custom module, name who owns the code repository, and confirm that the client receives the code under the AGPL-3.0 license that covers Decidim itself.

Moderation and process design

Staff time to design participatory processes, write the rules for proposals and votes, train moderators and run the first campaigns. Most of this is one-time setup, but moderation continues for as long as processes run and tends to grow with participation. Ask who staffs moderation, how many hours the quote assumes per process, and whether the partner trains the client's team to take over the work.

Translations

The cost of translating the interface, legal text, process pages and content into each language the organization serves. Initial translation is one-time, while new content, new components and any release that changes interface strings create recurring work. Ask how the quote counts languages, who maintains the translation files, and whether any machine-assisted translation is reviewed by a fluent speaker before publication.

Upgrades, support and security patching

Recurring work to stay on a supported release. Decidim supports only the last two minor versions with security updates until version 1.0, currently 0.32.x and 0.31.x, and upgrades must move one minor version at a time. Implementers also have a grace period of 2 months to apply patches for standard vulnerabilities and 4 months for critical ones. Ask for the annual calendar, the support hours included and the rate for out-of-hours incidents.

Identity and verification services

Costs for connecting Decidim to an identity provider, a national eID or a verification service so that only verified participants can vote or sign. The integration is usually one-time, but verification vendor fees, per-check charges, certificate renewals and provider changes recur. Ask which party holds each vendor contract, who pays for each verification, and who maintains the authorization handlers after every upgrade.

What makes a Decidim platform cost more or less over time?

This table lists the drivers that change the ongoing effort of running a Decidim platform, why each one scales the work, and what an organization can do to keep it contained. Read it before requesting a quote, since most drivers affect build, hosting and upkeep at the same time. Drivers marked by number of spaces, users and languages scale most in the years after launch, not only at go-live.

Driver	Why it changes the cost	How to keep it down
Number of participatory spaces and components	Each process, assembly or initiative adds configuration, content, moderation and testing. Components such as proposals, meetings, surveys and participatory budgets each carry their own settings and upgrade surface.	Start with the spaces and components needed for the first launch, and reuse templates for later processes instead of building each one from scratch.
Expected users and peak traffic events	Voting windows and announced debates create short bursts of load that drive database, background job and file storage sizing. Peaks, not averages, set the hosting footprint.	Ask for a load profile based on past participation figures, schedule large votes with notice, and confirm hosting can scale for the peak window.
Number of languages and translation volume	Every enabled language needs translated interface text, space content and ongoing review. New content published in each language adds moderation and proofreading work for the life of the platform.	Limit the launch to the languages the audience needs, agree a translation workflow, and set a rule for which content must be translated before publication.
Custom modules and third-party integrations	Custom code, such as a bespoke component or a connection to a case management system, must be tested and maintained through every Decidim and Ruby on Rails upgrade. Integrations also need their own monitoring.	Prefer configuration and existing components where they meet the need, document each custom module, and budget for its upkeep as part of the support scope.
Number of environments	Development, staging and production copies each need deployment, data refresh, patching and access control. Testing upgrades against a realistic copy takes effort before any change reaches the public site.	Keep the environment count to what the upgrade process needs, automate builds, and reuse the same deployment definitions across environments.
Identity and verification requirements	Connecting to an identity provider, a national eID or a custom authorization handler adds integration testing, security review and support requests from participants who cannot complete verification.	Decide which actions truly require verification, use existing social or organizational providers where the policy allows, and document the verification steps for participants.
Hosting model (cloud accounts, data center or air-gapped)	Cloud accounts carry recurring infrastructure charges and managed service choices. Data center and air-gapped deployments add hardware lifecycle, manual patch delivery and longer change windows.	Confirm which hosting model the organization's policy allows, ask the hosting provider for recurring cost estimates, and plan patch delivery for air-gapped environments early.
Number of organizations on one instance	Multiple organizations on a single Decidim instance share the codebase but need separate configuration, branding, moderators, providers and data handling. Each additional organization adds administration and testing.	Decide early whether separate organizations need separate instances, group shared settings, and keep a clear owner for each organization's content and access.

How the cost model is built step by step

The sequence starts from the intended use and ends with a model the client can maintain, so every recurring and one-time line traces back to a decision, a supplier quote or a stated assumption. Each step closes with a named output that feeds the next.

Inventory the intended use
The client and DeployOpen list the intended use: which participatory spaces (processes, assemblies, initiatives) will run, which components (meetings, surveys, proposals, participatory budgets, accountability tracking) are needed, how many organizations will share one instance, which languages and verification rules apply, and which custom modules are expected. Each item is marked in scope, out of scope or open. The output is a signed-off use inventory that every later cost line refers back to. The step is done when the business owner confirms that no open items remain.
Choose the architecture and hosting model
Decide how Decidim will run inside the client's own environment: a manual Rails installation or Docker, the hosting option (cloud account, data center or air-gapped network), and the supporting services production needs, including background jobs, file storage, SMTP, maps and geocoding, and social login providers. Confirm the Ruby, Node and database versions for the chosen release against the installation documentation, because v0.32 and v0.31 specify different runtimes. The output is an architecture decision record with one hosting option per scenario and a cost line for each component. The step closes when the client's infrastructure team accepts the design.
Build the one-year cost lines
Split the first year into one-time and recurring lines. One-time lines usually include implementation, configuration, custom module development, data migration, initial translations and process design. Recurring lines include hosting, backups, monitoring, storage, email, security testing, moderation staff time, translation of new content and support. For each line, record who is paid (DeployOpen, a cloud provider, an internal team or a translator) and the basis for the figure: a written quote, an internal rate or a stated assumption. The output is a one-year cost table with those fields completed. The step is done when every line has a basis and an owner.
Map the version calendar into the model
Apply the release and security policy to the recurring lines. Until version 1.0, Decidim supports only the last two minor versions with security updates, currently 0.32.x and 0.31.x, so the platform must move forward before an older branch loses coverage. Upgrades go one minor version at a time, each with its own release instructions and a database backup, so the model needs a recurring upgrade line that includes a test environment and staff time for each step. Security reports carry a grace period of 2 months for standard vulnerabilities and 4 months for critical ones before disclosure, which sets how quickly patches must be applied. The output is an upgrade schedule with costs attached to each cycle.
Extend the model across several years
Repeat the build across the planning horizon, carrying one-time lines forward only where they recur. Later years add upgrade cycles from the version calendar, maintenance of custom modules after upstream changes to Rails or Ruby, hosting changes, staffing changes, and translation volumes that grow with the number of processes. Each escalation is written as an assumption with its source, such as a provider price list or an internal salary band, so the reader can change it. The output is a multi-year cost table with a yearly total and an assumptions register. The step is done when the largest assumptions and their effect on the total are visible.
Compare scenarios against the SaaS quote
Place the self-hosted scenarios beside the commercial SaaS quote on the same scope. Normalize the inputs: the same participatory spaces and components, languages, verification rules, data location, uptime expectations, support hours and exit terms. Ask the SaaS vendor in writing which items are included, which are add-ons and how prices change over the contract term. Record what each option does not cover, since an open gap can change the ranking. The output is a side-by-side comparison with every gap labeled. The step closes when the decision owner can see which assumptions decide the result.
Hand over the model with its assumptions
Transfer the model to the client's finance or platform owner with the use inventory, architecture record, assumptions register and comparison. Walk through how to change an input and where each figure comes from. Set review triggers: a new minor release, a security advisory affecting a deployed component, a hosting price change, a staffing change or a new participatory space. The output is a handover pack and a short review log. The step is done when the client team updates one assumption on its own and the totals recalculate correctly.

Where Decidim cost estimates usually go wrong

Many Decidim estimates come in low for the same reason: the license is free, so the model centers on the first launch and skips work that repeats. The six gaps below each carry a cost that recurs or grows as the platform ages. Use the check on each card to test a quote before you sign it.

Costing only the initial build

The first deployment is the cost most teams model, but Decidim ships as a series of minor releases, and the supported lines are 0.32.x and 0.31.x. Each upgrade needs staff time, a test run, a change window and rework of any custom modules. Check whether the model includes a recurring line for upgrades and ask the partner to show that line in the written quote.

Leaving out translation and moderation

Participatory processes publish proposals, comments and process pages in every language the community uses, and someone must translate and moderate them for as long as each process runs. This is recurring staff or contractor labor, not a one-time setup task. Check that the estimate names who translates, who reviews submissions, and how many hours each active process consumes.

Assuming a single environment

Many estimates price one production instance only. A safe upgrade needs a staging copy that matches production in authentication, mail, file storage and background job setup. Each extra environment adds hosting, data refresh and configuration drift checks. Confirm whether the quote covers staging, a test setup for custom modules, and who keeps those environments in step with production.

Underestimating moves between minor versions

Decidim's update guide asks teams to upgrade one minor version at a time, for example 0.29 to 0.30 before 0.31, and to follow each release's own upgrade instructions. A jump from an older release therefore means several full upgrade cycles, each with its own testing and sign-off. Count the hops between your current version and the target, and budget testing for every one.

Forgetting unsupported release lines

Until version 1.0, Decidim supports only the last two minor versions with security updates, currently 0.32.x and 0.31.x. The 0.30.x line and earlier receive no security updates, so a platform left there carries known exposure. Moving it onto a supported line can cost more than the estimate assumed when it treated the current system as up to date. Check the running version before you accept any budget.

Underestimating database upgrade work

Some Decidim upgrade steps change database structures, so the release instructions call for a database backup before any change is made. Restore rehearsals, migration runs against a production-sized copy of the data, and post-upgrade content checks all take staff hours. Check that the model includes a backup and restore test and enough time to run migrations before the production window opens.

How a self-hosted Decidim compares with an engagement SaaS subscription

A SaaS subscription bundles hosting, software updates and some support into one recurring fee, while a self-hosted Decidim removes the software license fee and moves hosting, upgrades, security patching and support to the owner. Decidim is free and licensed under the AGPL-3.0, so the question is not whether a license fee exists but who pays for each operational function and how often. A fair comparison therefore starts by listing those functions for both options, not by setting a subscription price beside a server bill. Before comparing anything, the reader should obtain the full SaaS contract terms, including the order form, the data processing terms, the service description, the support tiers, the included number of organizations and users, overage rules, and the notice period for price changes. Headline prices often exclude custom domains, additional organizations, extra storage, translations, identity provider integration, or premium support. Ask the vendor to state in writing which of these are included, which are billed separately, and what happens to the data and configuration at termination. The comparison must also hold the scope constant. Define the same set of participatory spaces and components (for example processes, assemblies, proposals, meetings, surveys, participatory budgets and accountability tracking), the same number of organizations and the same expected user and verified-participant volumes. Then check data residency and hosting obligations: where the SaaS stores data, which jurisdictions can access it, and whether your own policies require hosting in a specific cloud account, data center or air-gapped network. Self-hosting gives control over these points but makes your team responsible for meeting them. Customization and exit costs complete the picture. Custom modules, branding, a non-standard identity provider or a specific authorization handler are cost items on the self-hosted side, and they must be priced in both options if the SaaS vendor offers them at all. On exit, a SaaS subscription may charge for data export or limit the format of what you receive, while a self-hosted platform means you already hold the database and files. Ask each vendor how you would extract accounts, proposals and process history, and what that would cost in time and fees. Finally, treat the output as a model you can check rather than a verdict. Record each cost component, mark it as one-time or recurring, name who is paid for it, and identify the assumptions behind each number. Request written quotes for the self-hosted scope from a partner, and compare them with the SaaS contract as written. Where a figure is still missing, put it on the open questions list instead of filling the gap with an estimate.

Which recurring costs continue after go-live?

This table lists the cost lines that keep running after a Decidim platform launches, who usually pays for each one, and what to request in a quote. Use it to separate one-time build work from the monthly and yearly commitments your team will carry. Confirm each service with its provider, because plan tiers and editions exist only where that provider offers them.

Cost line	Who usually pays	One-time or recurring	What to ask for in a quote
Hosting and managed PostgreSQL	Client, to the cloud, data center or hosting provider	Recurring	Compute, database and storage sizing for production and staging, and who manages patching of the database service
Backups and disaster recovery environment	Client for infrastructure, implementer for setup and restore tests	Setup one-time, storage and standby recurring	Backup frequency, retention period, where copies are stored, and how often a restore is tested
Transactional mail delivery (SMTP)	Client, to the mail service provider	Recurring, usually volume-based	Expected monthly message volume, sending domain setup, and bounce and complaint handling
Maps and geocoding services	Client, to the map or geocoding provider	Recurring, usually usage-based	Which map tiles and geocoding calls are used, expected request volume, and the provider's terms for public use
File storage for uploads	Client, to the storage provider	Recurring, grows with uploads	Storage class, retention of attachments, and whether storage is replicated across sites
Security patch application	Client platform team or implementer under retainer	Recurring	Patch response times inside the vendor's disclosure grace periods, and who tests and deploys each patch
Version upgrades (one minor version at a time)	Implementer or client team, with a test environment	Recurring, one cycle per minor release	Effort per upgrade, Ruby and Rails compatibility checks, and custom module updates included
Support retainer	Client, to the implementer or internal team	Recurring	Response targets, covered components and custom modules, and what is excluded from the retainer
Moderation and content staffing	Client, through staff or contracted moderators	Recurring, rises with active processes	Moderation hours per process, escalation rules and who approves content
Translation of new content	Client, through translators or the implementer	Recurring, per new process or campaign	Languages required, word count of new content and turnaround expectations
Internal platform owner time	Client, from its own staff budget	Recurring	Named owner role, hours needed for administration, configuration and vendor coordination

How the cost picture changes by starting point

Organizations leaving a commercial engagement SaaS usually compare a subscription fee against the cost of running Decidim themselves. Decidim has no license fee because it is licensed under the AGPL-3.0, so the recurring lines move to hosting, operations, support and any custom work. The one-time lines grow, because data, accounts and public process history have to move across.

Recurring lines that grow: hosting, backups, monitoring, email delivery and staff time for moderation and process design, which the subscription previously covered in part.
Recurring lines that shrink: the vendor subscription and any per-module or per-seat charges in the current contract.
One-time lines that appear: data mapping, migration of participants and proposals, and a period of parallel running while the old contract ends.
Confirm first: the export formats the current vendor provides, whether accounts and consent records can move, and the contract end date.

Check the exit terms and data export rights in the current contract before you build any cost comparison.

What the organization needs to provide for an accurate cost model

A cost model for Decidim is only as accurate as the inputs the organization gives us, so the first task is to name who owns each one. Before any hosting, staffing or subscription figure is calculated, the organization should appoint a single named platform owner with authority to approve scope, budget and risk trade-offs. This person signs off the overall model and every assumption below. Without one accountable name, assumptions drift between departments, and the estimate quietly describes a platform nobody has agreed to run.

The scope inputs are the list of participatory spaces and components the organization intends to use. Decidim offers processes, assemblies and initiatives as spaces, and components such as meetings, surveys, proposals, participatory budgets and accountability tracking. Each enabled component adds configuration, moderation, testing and content effort, and some add hosting load. The process owner for each department should confirm which components will run at launch and which will follow later. The organization should also provide expected registered users, peak concurrent visitors during a voting window and the number of languages in use. Traffic estimates come from the communications team, and translation needs from the same people who will publish content.

The integration inputs are the identity sources, the authorization rules and the hosting constraints. The identity owner, usually the IT or digital identity team, should confirm which login methods must be supported, whether social logins are permitted, and whether a national or regional eID must be connected. Legal and records officers should state which actions require verified participants, such as voting or signing, and which data must stay in a specific country or cloud region. Data residency rules decide whether a managed SaaS engagement tool is even an option, and they change the hosting line of the model. Email delivery, maps and file storage requirements should be listed here as well.

The internal skills input is the most often overlooked. Operating Decidim requires working knowledge of Ruby on Rails, PostgreSQL and Linux server administration, and the current versions in the official documentation depend on specific Ruby and Node releases. The IT manager should record how many staff can perform these tasks, how many hours per month they can give, and whether they can cover on-call duties. A gap here does not stop the project, but it moves cost from internal salaries into a support retainer, which must be priced explicitly.

The last input is the commercial comparison. For a SaaS engagement platform, the procurement team should obtain the written quote and its full contract terms: subscription fees, implementation fees, user or volume tiers, data export rights, exit assistance, service levels, renewal increases and the notice period for cancellation. Comparing a one-time implementation and recurring hosting against an annual subscription only works when both sides cover the same components, languages and volumes. Finance should sign off the comparison period, the currency and the treatment of internal staff time, and legal should confirm that contract terms are reviewed before any figure is shared with decision makers.

Questions buyers ask before comparing Decidim with a SaaS quote

Is Decidim free to use for our organization?

Yes, the Decidim software carries no license fee. It is open-source software licensed under the AGPL-3.0, so your organization can install, run and modify it without paying a license to the project. The cost of ownership sits elsewhere. You pay for the infrastructure that hosts it in your cloud account, data center or network, for implementation, for any custom modules, for translations, for moderation and process design, and for upgrades and support. The AGPL-3.0 also sets conditions on modified versions that users access over a network, so ask your legal counsel how those conditions apply to your plans before you commit.

How long does a Decidim total cost review take?

The length depends on how many decisions are still open. A review that assumes existing hosting, standard components and one identity provider can move faster than one that compares hosting options, maps custom modules, sizes moderation staffing and prices translations. Time also depends on how quickly your team supplies inputs such as expected participant volumes, languages, existing contracts and verification rules. Ask for the timeline in the written scope, which should list the inputs you provide, the working sessions, the deliverables and the date the comparison is ready. Because most engagements are fixed-scope, the agreed scope is where the duration should be set.

Can our own team run Decidim without an implementation partner?

Yes, some organizations run Decidim with their own engineers. It can be installed manually as a Rails application or with Docker, and production setups must configure background jobs, file storage, SMTP, maps and geocoding, and social login providers. Whether your team can do this depends on its skills and capacity in Ruby on Rails, PostgreSQL, Linux server operations and security administration. Someone also has to read each release's upgrade instructions and apply them in order. List each task, name an owner and decide which gaps, if any, a partner should fill. DeployOpen plans, implements, customizes, hardens, backs up, upgrades and supports self-hosted platforms inside the client's own infrastructure under a written scope.

What does running Decidim need from our staff?

Running Decidim needs named owners for several roles. A product owner decides which participatory spaces and components run and how processes are configured. A platform engineer owns the servers, database, backups, background jobs and upgrades. A security administrator manages admin access, secrets, file uploads and patch monitoring. Moderation staff review contributions, and a communications or translation lead manages languages and public content. Legal or privacy staff define verification and data retention rules. Recurring work includes watching release announcements, scheduling upgrades, testing custom modules after each change and reviewing backups. Ask any partner for a responsibility matrix that shows which tasks they perform and which stay with your staff.

How often do we need to upgrade Decidim?

Upgrades are driven by the support policy, not by a fixed calendar. Until version 1.0, Decidim supports only the last two minor versions with security updates, currently 0.32.x and 0.31.x. Your platform therefore has to move forward whenever a supported branch is superseded. The update guide says to upgrade one minor version at a time, for example 0.29 to 0.30 before 0.31, to follow each release's instructions because some change database structures, and to back up the database first. Track the project's GitHub releases to see when patch and minor versions arrive, and plan your upgrade windows around them. Your staff or partner should test custom modules against each target version before the production upgrade.

What happens if our Decidim version falls out of support?

Versions 0.30.x and earlier are not supported with security updates, so a platform on those versions receives no fixes from the project. Decidim gives implementers a grace period of 2 months to apply patches for standard vulnerabilities and 4 months for critical ones before details are disclosed. Those windows are short compared with a multi-version upgrade that includes database changes, Ruby and Node changes and custom module work. Under the current requirements, v0.32 uses Ruby 3.4.7 and Node 22.14.x, and v0.31 uses Ruby 3.3.4 and Node 22.14.x. Ask for an upgrade assessment that maps each custom module and dependency to the target version before you need one.

How do we compare Decidim total cost fairly with a SaaS quote?

Build both options from the same inputs and the same time period. For Decidim, list one-time costs such as implementation, configuration, custom modules, translations and launch, and recurring costs such as hosting, backups, security testing, upgrades, support, moderation staffing and internal staff time. For a SaaS quote, confirm directly with the vendor which features, participant volumes, languages, storage, support levels and identity integrations are included, and what renewal increases, overage charges and exit fees apply. Compare data ownership, export formats, hosting location and the cost of leaving in both cases. Ask each provider for pricing and contract terms in writing, and have your procurement and legal teams read the SaaS contract before you compare totals.

How DeployOpen builds and hands over a Decidim cost of ownership model

DeployOpen builds a Decidim cost of ownership model around your own hosting, modules, staffing and upgrade plan, so the figures reflect your environment rather than a generic estimate. The model is written as a working document you can review, change and keep after the engagement ends.

How we scope

Agree the written scope for the cost model, including hosting targets, number of organizations and components in use.
List the cost lines to model: hosting, implementation, custom modules, moderation, process design, translations and upgrades.
Confirm which costs you will pay internally and which you expect to buy from a partner or vendor.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.

How we build

Build the model as a spreadsheet with stated assumptions, one line per cost component and a clear owner for each.
Map each recurring cost to its driver, such as Ruby and Node version changes, database size or number of active processes.
Check the upgrade assumption against Decidim's rule to move one minor version at a time with a database backup first.
Test sensitivity by changing key assumptions, such as the number of supported releases you plan to run and staffing levels.

How we hand over

Deliver the model with a written assumptions register, source notes and a short guide to updating each figure.
Walk through the model with finance, IT and participation staff so each assumption has a named internal owner.
Provide a list of questions to confirm with hosting providers, vendors and your own teams before the figures are used in a budget.
Leave the working files in your control so your team can rerun the model after each Decidim release.

How we support

Offer ongoing support and periodic model reviews as a retainer when your Decidim platform changes.
Update the model when a new minor release or security advisory changes the upgrade or staffing assumptions.
Review the model against your actual hosting invoices and internal effort records at agreed intervals.
Available retainers cover continuous testing and upgrades, priced from the written scope rather than a published list.