Case Study — Docker Hardened Images
One designer, eleven engineers, one PM, and four months to build something Docker had never built before. We shipped in two.
One designer. Eleven engineers. One PM. A new leadership team with a mandate to make Docker serious about security. And a product Docker had never built before.
There was no playbook. Nobody in that room had done this before, including me. So I did what I always do when things are unclear: I started making things. Rough sketches, early flows, anything that could get a reaction and move the conversation forward. Design became the thing that kept thirteen people oriented.
There was no playbook. So I did what I always do when things are unclear: I started making things.
We had four months. We shipped in two. From idea to GA to seven figures in ARR in under twelve months.
The catalog hit every quarterly target on the way to 577 repositories. Weekly pull volume grew 11x. And nearly half of all DHI organizations pull a customized image every week. That number matters: customizations were the hardest thing we built, and the thing the business bet on to convert free users into paying customers.
The weekly design review I started with five people grew to over forty. In a team with no playbook, that room is how we stayed aligned long enough to ship all of it.
Companies were pulling software from all over the internet, and nobody could say with confidence which versions were safe. Security and platform teams were burning hundreds of hours a month vetting base images and chasing CVEs. Docker was already where developers found images, but not where enterprises went for security guarantees.
The obvious framing was simple: make Docker the trusted source for verified, up-to-date images. Too simple. The real design problem was that enterprise security teams needed governance and audit trails. Developers needed something fast and familiar. And the business needed to convert free users into paying customers without a sales call in the middle. Three pulls in different directions, and the design had to hold all of them at once.
Security teams needed governance. Developers needed speed. The business needed conversion without a sales call. The design had to hold all three.
I came in without a security background. I started by studying Chainguard and RapidFort, mapping where Docker's users already lived in the workflow, and sketching early concepts to align the team before anyone wrote a line of code.
The early team was classic startup mode inside a larger company: no clear roadmap, competing opinions, hard deadline. I kicked things off with a Hot Potato brainstorm around one question: what should the first experience look like for first-time versus returning users? From there I mapped new functionality against the existing Hub architecture and roughed out the user journeys that became the foundation of the Early Access Program.
To keep a fast-growing team coherent, I started a weekly design review. Five people at first, across design, product, and engineering. Over forty by the time the Early Access Program wrapped. It wasn't just a review. It became how the group made decisions together.
Mirroring was the first genuinely new capability in the product. Before DHI, users downloaded images from Hub. Mirroring meant copying an image into your organization's namespace, where Docker keeps it automatically patched on an SLA-backed schedule.
I designed the full mirroring experience: the flow, the management UI, the error states, the governance model. A core decision was making mirroring an Org Owner-only action, so security teams could trust that approved base images were controlled at the organization level, not by individual developers.
The trickier problem was infrastructure mismatch. Enterprise customers rarely pull directly from Docker Hub. They route through their own registry: Artifactory, Harbor, ECR. What most users didn't realize is that once an image leaves Hub, it's a static copy. It stops receiving patches.
The solution was in-product communication with a security layer built in, surfacing the patch implications directly in the management experience. Make the right behavior the obvious behavior, without adding friction to the flow itself.
The data says it landed. Essentially every org that mirrors an image goes on to pull it, and the median time from mirroring to first pull is zero days.
Customers also needed to adapt images for their own environments (CA certs, packages, environment variables) without losing the security guarantees they were paying for. I led the early explorations on customizations: the permission model, the tagging structure, what the UI had to communicate about the security implications of adding packages.
One deliberate decision: open customizations to any user with repo access, not just Org Owners. Mirroring needed tight governance. Customizations needed to be in the hands of the engineers doing the work.
Mirroring needed tight governance. Customizations needed to be in the hands of the engineers doing the work.
Before I could see it through, I was pulled onto another 0-to-1 product. The team built the shipped customizations experience on top of the foundation I'd laid.
When I was brought back, this time as part of a larger shift around Docker's new AI initiatives, I could see which decisions had held. The mirroring architecture was intact. Parts of the customizations UX had drifted, but the underlying model was sound.
Bulk Customizations was the project I picked up on my return. Large organizations were recreating the same configuration manually for every mirrored image, which was unsustainable at scale. Bulk Customizations let them apply one configuration across their entire library in one action. It shipped in April 2026.
The data validates the original permission call: paying customers customize at nearly four times the rate of free users, 35% versus 9%. Customization is the clearest behavioral signal that an org has moved from evaluating DHI to depending on it.
Months later I took on the self-serve activation flow, a monetization effort meant to move users from free to trial to paid without a sales call. During that work, the growth team introduced a stepper targeting the same conversion goals in a way I thought would undermine the experience. I made the case against it in a short deck, and the team pulled it back. When self-serve was deprioritized due to engineering constraints, the stepper went live to 100% of users. We monitored the results: 356,957 views, a 0.44% click rate. That was enough. My PM and I got it removed and self-serve reprioritized. That work is shipping now.
I made the case in a deck and won the room. But the decision only stuck once the data made it undeniable.
The biggest shift this project made in how I work: I stopped thinking of design as the thing that comes after direction, and started treating it as the thing that creates direction. In a team with no playbook, the sketches were the strategy conversation. That's a muscle I'll use everywhere.
Reorgs happen. Projects get paused, priorities shift, and the work you were leading is suddenly someone else's to finish. What this project taught me is that design work needs to be legible enough to survive that. Not just the files, the decisions behind them.
The work survived my absence. That's the real test of whether the thinking was sound.
The stepper taught me that a good argument isn't enough on its own. I made the case in a deck and won the room, but the decision only stuck once the data made it undeniable. Influence at this level means knowing when to argue and when to let the numbers do it.
And the permission model was the decision I'm most glad I got right. Splitting governance — tight on mirroring, open on customizations — was a bet on how organizations actually work. A year later, the adoption data proved it out. That's the kind of call I want my work judged on.