No single figure answers this question honestly, and a provider who quotes one before asking about languages, member accounts, and the operating period is guessing. The defensible way to budget a project platform is to cost four blocks separately: design and build, content and translation, hosting and licences, and operation with handover. How the money splits across the blocks follows from one early decision: whether you build custom, configure an existing product, or reuse a platform someone already operates. The most common mistake is budgeting the build and leaving the operating period, the longest phase of the platform's life, without money or named hours.
A commercial website is marketing collateral with a market rate. In an EU project, a platform is a contracted deliverable with a lifecycle: it must exist by a milestone, serve the target groups named in the application, often in several languages, and in most calls outlive the funding. Two proposals can both write "project platform" and mean deliverables with very different costs: a small public site with a news feed at one end, a moderated multilingual member area with a resource catalogue at the other.
So the useful first question concerns scope, not price: what must exist, by when, in which languages, for whom, operated by whom, and until when.
Building custom maximises design and build and leaves every later block with the consortium. It is justified when the platform itself is the innovation, functionality that does not exist elsewhere.
Configuring an existing product, a CMS, a community platform, an event tool, shrinks the build block, moves money into recurring licences, and accepts the product's constraints in exchange.
Reusing an operated platform, one that a partner or provider already runs as a service, makes the build block smallest and turns most of the budget into a service line. The operating period is priced from the start, because the operating period is the contract.
A deliverable described as a community sustained throughout the project, with a budget that sits entirely in the first year, tells evaluators that nobody planned the sustaining part.
The build gets budgeted because it is visible: it produces an invoice, a launch, a screenshot for the interim report. Operation is invisible at proposal time, so it gets absorbed into vague partner effort or dropped. The platform launches mid-project, the line is spent, and from that month nobody is paid to approve members, answer questions, publish updates, or install security patches. Our piece on what happens to EU project websites after funding ends documents where this leads: the death usually begins well before the end date, when operation stops being anyone's funded job.
The corrective is one habit: every digital deliverable gets two budget lines, one to build it and one to operate it, and the operate line covers every month between launch and the end of the sustainability promise. This is how we quote at StrandsUnited, where designing, building and operating platforms is one engagement, because a platform priced without its operating period is only half priced.
In lump-sum Erasmus+ budgets, platform costs live inside work packages, usually dissemination or a dedicated digital work package, split between partner staff costs (content, editorial work, coordination) and subcontracting (specialised build work, hosting, an external operator). The Erasmus+ Programme Guide sets the frame for what those work packages must show. In Horizon Europe, partner effort is personnel cost while an external provider is subcontracting or purchased services, and subcontracting has to be declared and justified in the proposal rather than discovered during implementation.
Whatever the programme, one rule prevents a known class of rejection: the narrative and the budget table must tell the same story. If the text promises a moderated multilingual member area for the full duration, the table must show effort in every reporting period, not one spike around the launch milestone. Evaluators cross-read the two documents, and a mismatch reads as careless or padded, so name the deliverable identically in both, give it one owning partner, and make the effort timing match the promise.
These factors move cost predictably, and naming them shows you understand the deliverable.
Quotes diverge because briefs leave scope open and every bidder closes the gaps differently. Fix the scope and quotes converge. Specify:
That last line puts the operating period in writing before the grant is even submitted.
If every question has an answer, the budget line will survive both the evaluation and, harder, the years after launch.
StrandsUnited designs, builds and operates platforms for EU projects and communities, including Impactful, the community impact platform of the Founders community in Cyprus, so the operating block above comes from monthly practice rather than theory. Our grant intelligence engine includes a consortium graph of 114,731 organisations and 83,490 projects, built from CORDIS and Erasmus+ open data covering 2014-2027, and the number of finished projects in that data whose platforms no longer resolve is what convinced us to give operation its own cost block.