Stamp is the design system we're building for PostNL to bring style, accessibility, and tech together across all of their digital products. Working on it is where I've put my views on accessibility, standards, and clean component APIs into daily practice.
My role
I worked on Stamp for over a year together with my tech lead, the two of us as the developers from De Voorhoede. The wider core team includes a product owner, designer, and accessibility expert from PostNL.
In a team this small, my work goes beyond writing components. I shape component APIs, propose and implement accessibility patterns, maintain the CI pipeline, and document the system. I also lay the groundwork for new system areas and tooling, mentor developers joining the project, and work closely with the designer to test design choices and push for stronger UX outcomes.
Three packages, one system
Stamp ships as three separate packages: Angular, React, and native Web Components. PostNL runs a wide range of projects and platforms, and the three packages exist so every team, regardless of their stack, can adopt the system.
That decision sits underneath almost everything else on the project. It shapes how we design components, how we document them, and how new contributors get up to speed.
Designing for three at once
Web Components accept attributes and slots, not complex objects, while Angular and React happily take rich props. The shape of an API has to work in three idioms at once, so we lean toward composition over configuration: small focused components that compose together, instead of larger components configured through rich props. It's a constraint that tends to leave behind anything clever that only works in one framework, and what's left is usually the better design anyway.
Accessibility on Stamp isn't a checklist applied at the end, it's a property of how the system is built.
Accessibility as a discipline of the system
This shows up clearly in how we approach accessibility. Most of the work happens in HTML and CSS: semantic elements as the default, logical properties so layouts behave across writing modes, lang-aware patterns so localized text follows the document language. ARIA only enters where the platform genuinely doesn't have an answer.
What made this approach possible is the team. Sparring with our accessibility expert throughout the project is the difference between code that passes audits and a system that's actually accessible.
Laying the groundwork for AI
I laid the foundation for Stamp to be consumed by AI tools. Two pieces of work fit together to make that possible.
The first is publishing our packages to Figma Make, so designers prototyping there always have the latest components at hand. I worked out the publishing flow and wrote a separate npm configuration so it could be added cleanly to CI as part of our regular release process.
The second is a GUIDELINES.md for every component, written in plain language describing how each component should and shouldn't be used. AI tools need this kind of context to generate correct code against the system instead of guessing, and the same files double as developer-facing documentation.
What I take from it
Stamp taught me a lot. Working in a small team with broad responsibility pushed me past writing components, into API design, documentation, communication with the teams consuming our work, and the kind of long view that building software for other developers demands. Three packages deepened my preference for standards-driven, framework-agnostic foundations. And working alongside a tech lead, a designer, and an accessibility expert I could spar with throughout the project made the learning curve a steep and welcome one.
The team made it land. Sharp, engaged, generous with their expertise, willing to push back when it mattered. The kind of colleagues you remember.