Custom digital product passport software development
The ESPR is in force, but no delegated act yet specifies which data your digital product passport must contain. Anyone selling you a ready-made DPP package today is selling a bet on rules that have not yet been published. What is settled is the structure: a unique identifier, a data carrier on the product, and tiered access per audience. You can build that now, and the fields slot into it later.
What is and isn't settled
Regulation (EU) 2024/1781 replaced the Ecodesign Directive and extended it from energy consumption to the durability, reparability and circularity of almost all physical products. The regulation itself, however, sets few concrete product requirements. Those come per product group, in delegated acts that the Commission publishes step by step.
The April 2025 working plan sets the first priorities, including textiles, aluminium and tyres. As of now, no product-specific delegated act has been adopted; the textile act is expected at the end of this year or the beginning of next. After that comes a transition period of at least eighteen months before the requirements actually apply.
That is the squeeze, and it is the reverse of what vendors tell you. You cannot yet know the list of fields, so you cannot buy it either. What you can do is answer the question nobody will answer for you: at what level do you identify a product, where does the data that will go into the passport live, and who may see which part. That work is the same regardless and, at most companies, will take longer than eighteen months.
If you work with wood or paper, a second provenance record runs alongside the passport. See the chain of custody standards of FSC and PEFC.
How we build this
Here, the unit is not the list of fields but the identification. Once you have settled what a product is and where its data comes from, every later field requirement becomes a configuration setting.
Does a model get a passport, a production batch, or each individual item? This is the most consequential choice in the entire project, because it determines how many passports you manage and whether you can link them to a physical object via an app.
Material composition, origin, repair information and spare parts are, at most companies, scattered across PLM, ERP, specification sheets and the procurement inbox. Gathering that is the real work, not displaying it.
We build the passport as a schema that you extend yourself, with version control per schema. When the delegated act for your product group appears, you add fields rather than starting over.
We run the system through one product line and show what is missing. That list is usually longer than expected, and it is the reason to start now.
What the software actually does
The passport registry carries everything; the data carrier and the public view follow from it. Which components you need depends on your product type and your position in the supply chain.
Passport registry with unique identifier
A unique identifier per product, batch or item, to which everything else is attached. The system ensures that an identifier stays unique and is never reused, because a passport must still point to the same object years from now.
Schema per product group, configurable
You define the fields of a passport yourself and extend them as soon as the requirements for your product group appear. Each schema gets a version, so an older passport remains readable against the schema that applied at the time.
Creating and managing data carriers
A QR code or other carrier that points to the passport, with a permanent web address so the link keeps working even if your system changes later. Without that separation, you print codes you can no longer move.
Retrieving data from suppliers
Your supplier, not you, knows the composition and origin of components. A portal where each supplier delivers its data per component works better than an email exchange where nobody can see what is missing.
Layered access per target group
A consumer, a repairer, a recycler and a supervisory authority do not see the same thing. The regulation assumes that layering, so the rights model is not an extra but a requirement.
History kept per passport
Who changed which data, when, and on what basis. A passport lasts as long as the product, which can be longer than the supplier who supplied the data.
Who we build for
Your position in the chain determines which part of the passport you complete yourself. Four situations.
Manufacturers
You make the product and determine its composition, so most of the passport comes from your own systems. Your customers will ask you for the data before the obligation takes effect, and whoever gets that side in order becomes the supplier of choice.
Brand owners and private label retailers
You have the product manufactured and place it on the market under your name. The obligation therefore lands with you while the data sits with your manufacturer, often outside the EU. Requesting the data is then the entire job.
Importers and distributors
You import products and are often the first to place them on the market in the Union. Your supplier does not know the regulation and has no reason to study it, so the request must come from your side and must be simple. The same challenge arises with the EUDR, where you must demonstrate origin down to plot level.
Online sales
A product passport touches your product information: the same data, a different presentation, a different audience. If your range runs through a connected PIM or webshop system, the passport layer is an addition to it rather than a second administration.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Technology and integrations
Everything the delegated acts will prescribe should be configurable and stored per version. What is hard-coded will have to be rebuilt once your product group comes up for review.
Why Appfront
We do not sell a list of fields that does not yet exist
There is no delegated act yet. We build the structure and leave the fields open, and we make clear which part of your investment only gains value once your product group comes up for review.
The identification is the decision that matters
Model, batch or individual item determines the scope of your entire passport administration. We put that choice first rather than letting it follow from a package choice.
The data sits with your supplier
You cannot fill a passport with what you do not know. We build the supplier side through integrations and a portal, and make visible what is missing.
Eighteen months is shorter than it seems
After publication of the act for your product group, a transition period of at least eighteen months applies. Gathering supply chain data takes longer than that at most companies.
Security and privacy
A product passport is partly public, which makes the security question unusual: the aim is not to lock things away but to show exactly enough. The regulation assumes layered access, whereby a consumer sees less than a recycler and a supervisory authority sees more than either. We set up those layers as a rights model rather than as separate views, because two views of the same data drift apart over time.
The confidential side lies with your suppliers. Material composition and origin sit close to their recipes and their purchasing position, and they will only share that if they know who can see it. In the portal, a supplier therefore sees only their own components. On the storage side, a passport lasts as long as the product does, so history and schema versions must stay readable long after the source has gone. How we handle security ourselves is set out in our information security policy; reports from outside come through our CVD policy.
Frequently asked questions about the ESPR and the digital product passport
That varies by product group, and none of them is final yet. The ESPR works through delegated acts; only once one has been published for your product group does a transition period of at least eighteen months begin. Textiles come first and are expected around the turn of the year, which brings the obligation there towards 2028. Check the position for your own product group, as it may come later or earlier.
You can buy a system, but no one can tell you which fields it should contain, as those have not yet been fixed. What is known is the structure: a unique identifier, a data carrier and tiered access. Anyone promising you a fully completed passport today is filling it with assumptions. We build the structure and keep the fields configurable.
That depends on your product group and will be set in the delegated act. The difference is considerable: a passport per model is a handful of records, while a passport per item runs into the millions, which calls for a very different system. Because the choice carries real weight, we place it at the front and build so that you can refine it later without starting over.
A PIM describes a product in order to sell it; a passport describes it in order to repair, reuse and recycle it, and it is partly aimed at parties who are not customers. The data partly overlaps. We therefore integrate with what you already have rather than setting up a second product administration.
For importers this is the hardest part, because your supplier has no obligation and no stake in it. What works is keeping the request as small as possible, in their language, with a portal that shows what is still missing. What does not work is a spreadsheet with two hundred fields. Start early as well, since the first round rarely yields usable answers.
The data overlaps, but the systems do not. The PPWR concerns packaging and its recyclability, extended producer responsibility concerns weight per category, and the passport concerns the product itself. It pays to collect the item data once and use it for all three.
They must keep working. A passport lasts as long as the product does, and for furniture, machines or building materials that is far longer than the period you carry the model. That is why we give the data carrier a permanent web address and keep the schema the passport was created under, so an old passport remains readable.
That depends on the identification level, the number of product groups and whether the supplier portal needs to be included. The register with the schema structure is usually quick to put to use and delivers the most value, as it gets the inventory under way; the portal and integrations cost more. We give a reasoned estimate after the discovery phase.
Preparing for the digital product passport?
Take one product and try to write down what it consists of, per component and per origin. Wherever you then need to make a call, that is where the work lies, and that work does not depend on the list of fields still to come. We build this as a standalone application and as part of a broader custom software development project.