Building your own battery passport system is feasible, but the work is mostly invisible regulatory plumbing rather than the visible web page. You take on the implementation of the Annex XIII access tiers, ISO/IEC 15459 identifiers, the per-battery model required by Article 77(1), QR generation, an immutable URL scheme and durable hosting for the full retention period.
| Capability | In-house build | Battery passport tool |
|---|---|---|
| Per-battery passport model | You design it correctly yourself | Built in |
| Annex XIII tier enforcement | You implement server-side gating | Built in |
| QR generation (print-grade) | You build it | Built in |
| Immutable passport URL | You design the scheme | Built in |
| 10-year retention | You own hosting durability | Provided |
| Regulatory updates | Your team tracks and implements | Maintained by the vendor |
- In-house suits teams with platform engineering capacity and custom integration needs.
- A tool suits teams that need a compliant passport quickly with predictable cost.
- Either way, the per-battery granularity and access tiers are non-negotiable.
Frequently asked
How long does it take to build a battery passport system in-house?
It varies, but a correct implementation involves more than a web page: access-tier gating, unique identifiers, QR generation, an immutable URL scheme and durable long-term hosting. This typically takes weeks to months, while a dedicated tool ships these pieces pre-built and leaves only your data to collect.
What do most in-house builds get wrong?
The two most common errors are building per-model rather than per-battery passports (a breach of Article 77(1)) and failing to enforce the Annex XIII access tiers on the server side.