What Does a DPP Project Cost? The Work Your Budget Should Include

A software licence is not a project budget

Businesses planning a Digital Product Passport often ask first about the platform price. Yet the overall budget depends just as much on the readiness of product data, the systems that need connecting and the team responsible for operation.

Two businesses with similar numbers of products can therefore face very different workloads. A structured data set with clear responsibilities is a different integration challenge from numerous manually maintained files without shared identifiers.

This article does not offer blanket market prices. It explains which work packages belong in a transparent calculation and which questions make offers easier to compare.

Define the scope first

Before comparing costs, define the planned outcome. Is the project a limited pilot, a product family or a rollout across several sites? Will passports operate at model, batch or individual item level? How frequently will the data change?

Within the ESPR framework, specific data requirements and granularity are established for the relevant product group. Budget assumptions should therefore distinguish between binding requirements and planning assumptions. Source: Regulation (EU) 2024/1781, Article 9.

A sound scope describes at least the product groups, number of relevant records, languages, data sources, participating roles and planned integrations. Without this context, two quoted totals are difficult to compare.

1. Requirements and project organisation

At the start, requirements need to be assessed, owners appointed and decisions made. This work is necessary even when the software can be deployed quickly.

Allow time for product management, IT, quality, procurement and other relevant departments. Not everyone needs to be involved continuously, but each relevant data set and approval should have an accessible owner.

Coordination is often underestimated. Who decides when material statements conflict? Who approves the release of supporting evidence? A technical interface alone cannot answer these questions.

2. Data inventory and preparation

Existing data must be located, mapped and checked. This may include removing duplicates, standardising units, linking evidence and resolving missing information.

Estimate the effort using a representative sample. A single perfectly maintained product tells you little. Include older products, several variants and records from different suppliers.

Useful measures include the number of unresolved mandatory fields, the share of evidence with an unambiguous product link and the average time needed to resolve a problematic record. The results indicate whether the budget is likely to be driven more by data work or by technology.

3. Interfaces and system integration

A one-off file import has different costs from an integration that is maintained over time. Interface work includes not only development but also field mapping, test data, error handling, documentation and subsequent changes.

Ask suppliers specifically:

• Which systems and data flows are included?
• Who creates and maintains the business field mapping?
• How are failed transfers handled?
• Which testing and acceptance activities are included?
• Which subsequent changes count as additional work?

A technically successful import does not prove that the content has been mapped correctly. The DPP data quality checks can help define acceptance criteria.

4. Labelling and integration into processes

A product passport must reliably lead to the correct product. Allow for creating and assigning identifiers and for integrating suitable data carriers into packaging, printing or production processes.

Depending on the product and applicable requirements, material, placement, readability and durability may matter. Testing with real products and actual site processes is another part of the work.

The data carrier is only one part of the system. Our article “A QR code alone does not make a Digital Product Passport” explains the connection between the access point and product information.

5. Platform and ongoing operation

Platform pricing may depend on users, passports, data volume, interfaces, support or other usage measures. Check the agreed billing model and ask for a scenario showing the effect of expected growth.

Operation also includes updating content, resolving data errors, managing access rights, monitoring transfers and maintaining supporting evidence. These tasks continue after launch.

The European Commission describes detailed product data as being stored in a decentralised way. Responsibility for keeping it available therefore belongs in operational planning. The central registry does not remove this work. Source: European Commission – DPP FAQs.

A simple cost model

Separate one-off costs from recurring costs. The following can serve as an internal planning structure:

One-off: requirements and design + data preparation + integration + labelling + training and acceptance.

Recurring: platform and hosting + data maintenance + interface support + support services + regular review.

Include internal working time as well as external services. Mark uncertain assumptions and calculate at least a base scenario and a growth scenario. A justified contingency for unresolved data or integration questions is more informative than an unexplained flat allowance.

Use a measurable pilot to improve the estimate

A limited pilot should show more than a passport on a screen. Measure how long data preparation takes, how many questions arise and how much work a change requires.

These values support a more grounded estimate for additional products. Alongside a technical result, the pilot provides a better basis for rollout decisions.

To discuss the scope of your project, tell SimpleDPP about your product groups and existing data landscape. A clearer starting point makes it easier to discuss the actual effort involved.