Shipping a catalog of safer software on time for Red Hat Summit
Developers needed to see why Red Hat's hardened images, pre-secured building blocks for apps, are safer. We launched the catalog as its own app and shipped on time for Summit. A principal designer led it. A product designer and a UX developer built it with AI tools they made themselves.
The problem
Most apps are built on ready-made software packages called container images. Security scanners flag hundreds of known flaws in a typical one. Developers didn't create those flaws and can't fix them, and the few that matter get lost in the noise. In November 2025, Red Hat announced Project Hummingbird to offer smaller, locked-down images, each with a full list of what's inside. Developers needed one place to find them, see why they're safer, and switch.
The call that protected the launch date
The plan was to launch inside Red Hat's existing product catalog, an older shared site. That would have put the Summit date at risk. We launched the catalog as its own app instead, with a plan to fold it back in later, and it made the Summit date.
Our principal designer led the conversations with the team that owns the existing catalog. I backed her on strategy and met with senior stakeholders to keep the decision moving. It held, and the path back stayed open.
What the team decided
- Show the proof up front. Each image's page shows its known flaws, a full list of what's inside, and where it came from, instead of in a separate compliance section. People switch to a safer option only when they can see why it's safer.
- Keep Lightwell separate. Our related security product serves different people with different jobs to do.
- Make it easy to find and follow. Search comes first, government compliance reports are built in, and developers can follow the images and flaws they care about.
How the team worked
A product designer and a UX developer worked as one unit, and the developer rebuilt the catalog on Red Hat's open source design system. They built AI tools that split every change into two steps:
- Design: write down the problem, decide within the design system, mock it up on the live product, and record the options they rejected.
- Build: a separate step builds what the design describes, then runs automated checks.
A person approves each change. A request could go from approved design to finished code in one working session.
Read the diagram as text
- Design skill: write down the problem.
- Design skill: decide within the design system and mock it up.
- A person approves the change.
- Build skill: build what the design describes and run automated checks.
- Build skill: the change becomes accepted code.
What I did
The method was theirs. My job was to give it room to work.
- I made the case for the UX developer role and paired that developer with the designer.
- Nobody in our org worked this way yet, so I backed them openly. Trying it was their call. If it went wrong, that was on me.
- I use AI tools heavily myself, so I could pressure-test their plan and help pick what to try first.
- I cleared blockers with other teams so the pair could keep moving.
- I set launch standards with Red Hat's web team.
Result
The catalog shipped on time, during Red Hat Summit in May 2026, as Red Hat Hardened Images (images.redhat.com).
Your team absolutely crushed it this go around!! The web site was sooooooo good, we didn't even really use the demos. When has that ever happened?