Custom app for the digital product passport
A product passport that only exists in a system is not a passport. It has to be attached to a physical item and still be retrievable years later by someone who doesn't know your system. That linking happens on the production line, in the warehouse or with the installer, usually with gloves on and without a reliable connection. That takes an app, not a screen.
Why the physical side is the hard part
The ESPR, Regulation (EU) 2024/1781, will soon require a digital product passport for each product group, accessible via a data carrier on or with the product. Which data must be included will be set per product group in delegated acts that have not yet been published. What those acts will not change is the task itself: someone has to apply a code and link it to the correct item.
That is exactly where it goes wrong. Printing a code is simple; linking it to the right serial number, the right production batch and the right moment is not. If you do it afterwards from a list, mix-ups creep in that you only discover years later, when someone scans a passport and sees the wrong product.
The second half is just as practical. A passport is not created once and then forgotten. A technician adds a repair, a recycler reads the composition, a returns department checks whether this item is yours. All of those moments are mobile, and many of them take place where there is no signal.
How we build this
The link between code and item is the core. If it is correct, the rest is a matter of display; if it is not, every passport is suspect.
At the end of the line, at the packing table or at goods receipt. We look at how many seconds there are, what the person is wearing and where things go wrong when there is a rush. That shapes the design more than the regulation does.
A scan that hits the wrong item is worse than no scan at all. We build confirmation and checks into the moment itself, because correcting afterwards means a passport has already left the building.
The app works offline and synchronises later, with a visible status per item. An app that stalls on a poor connection gets bypassed on the floor, and then nobody links anything any more.
We test not only applying but also retrieval: someone scans a product that is three years old and must get the right passport. That scenario exposes faults that stay invisible during linking.
What the app does in practice
The app does little, and that little must always work. Which components you need depends on where in the process linking and reading take place.
Linking a data carrier to an item
Scan the code and the serial number or batch, and the app records the link with a timestamp and the employee. When in doubt, it refuses rather than guesses, because a wrong link only surfaces years later.
Reading the passport on site
Scan a product and see the passport as the relevant role is permitted to see it. A technician sees parts and repair history; a member of staff handling returns sees provenance and warranty.
Fully offline operation
Linking and reading carry on without a connection; the app synchronises when there is coverage again and shows per item whether it has been processed. In warehouses and factory halls this isn't a luxury but a prerequisite.
Recording photos and condition
At intake, return or repair, a picture of the actual condition belongs with the record. The photo is attached to the item rather than to a separate file, so it stays with the passport.
Reporting deviations immediately
A code that cannot be read, an item without a passport, a batch that does not match. Reporting at the moment itself works; a note that is transcribed later does not.
Adding events to the passport
Repair, part replacement, change of ownership. Each event is recorded with who, when and where, so the passport tracks the item's life history and not just its factory settings.
Who we build for
How the app is used differs considerably by position in the chain. Four situations.
At the end of the production line
This is where the passport is created and where it is linked to the item. There is little time per unit, and any error made here travels with the product throughout its entire lifespan.
Warehouse and distribution
On goods receipt and dispatch it must be clear which item goes where and whether the passport goes with it. If your stock runs through an integrated warehouse system, the app plugs into that rather than sitting alongside it.
Fitters and maintenance
Outdoors, in a plant room or on a roof. The fitter reads the passport to see which component is fitted and adds what they have replaced. Working without signal is the norm here rather than the exception, just as with an inspection app.
Returns, repair and second life
On intake the first questions are whether this unit belongs to you and what has happened to it. The passport answers both, provided it can be scanned at intake and is not simply held in a system.
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
The app is the physical side of the product passport register, not a separate administration. Everything it records flows into the same register, so no second version of the truth emerges.
Why Appfront
You discover a faulty link years later
That is why we build confirmation into the moment of scanning, and the app refuses when in doubt. It costs a second and prevents a passport pointing at the wrong object.
Without signal it must simply carry on
We build offline as the starting point, not as an emergency measure. An app that stalls on a poor connection gets bypassed, and then the passport still does not exist.
One register, no second administration
The app writes to the same passport register as your office side, via integrations. Two records of the same item will inevitably drift apart.
Tested for retrieval, not just for application
We test the scenario where someone scans an old unit. That is what the regulation aims at, and where systems tested only on production data fall apart.
Security and privacy
A mobile device carries different risks than a desk computer. A phone in a factory hall gets lost, is shared between shifts and leaves the site. That is why we assign roles to the user rather than the device, limit the data stored offline to what the current task needs, and make sure a device can be disconnected remotely without stopping anyone else's work.
The read-out side requires its own considerations. Part of the passport is public and is precisely meant to be scanned by strangers; another part is explicitly not. In the app that separation depends on the logged-in role, so a fitter sees more than a consumer using the same code. What the app records is also evidence: photo, timestamp and employee must be tamper-proof, otherwise it is a story rather than a life cycle record. How we handle security ourselves is set out in our information security policy; reports from outside come through our vulnerability disclosure policy.
Frequently asked questions about the product passport app
Because linking and reading do not happen in one place. At the end of the line a fixed setup can work, but at goods receipt, for a field engineer on site and on returns it cannot. One app that does the same thing at all those moments prevents each department from developing its own way of working.
The obligation per product group will come through delegated acts that have not yet been published, so no, it does not apply to you yet. What matters now is whether you can identify an individual item at all. If you cannot, no field list will help you later, because you will not know which object the passport belongs to.
Usually yes, and that is often the cheapest route. If you already put a serial number or batch code on the product, the data carrier can attach to that rather than you applying a second code. Whether that is permitted under the requirements for your product group will be set out in the delegated act; we build the integration so that you can change carrier later.
That happens with products that have hung outside for years or been through a car wash. The app can then search by serial number or batch, and link a replacement tag to the same passport, recording that replacement. Without that route, a second passport is created for the same item, and that is the error you want to avoid.
Yes, but they see less. The regulation assumes tiered access: a consumer, a repairer, a recycler and a supervisory authority each see a different part. The public view does not require an app; it opens simply in a browser. The app is for your own staff, who see more and are also permitted to write.
The app is the physical side, the register is the administrative side. The two belong together and share a single data source. The register side, covering schema management, supplier data and access layers, is described on the ESPR software page.
Often, yes, and that is usually preferable to a second app on the same device. A field service app already has the login, the roles and offline working; scanning and linking come in as part of it. Whether that is possible depends on how your current app is built.
That depends on the number of scanning moments, whether NFC is needed and how heavily you rely on offline working. Linking and reading are usually quick to put into use; photos, events and integrations with ERP or WMS cost more. We give a reasoned estimate after the discovery phase.
Linking passports to products?
Go to the place where the code would be applied and count how many seconds each product takes. That figure shapes the design more than the regulation does. We build this as a standalone app and as part of a broader custom app or custom software project.