Clément Corbin Building a Scalable Icon Platform for a Technical Diagramming SaaS
Client: OneModel.app (Santa Clara, CA / full remote async workflow)
Stack: TypeScript, React, Next.js, Node.js, Express, Gatsby, PostgreSQL, TypeORM, SVGO, Github Actions, Github Packages
The product relied on thousands of cloud provider icons (AWS, Azure, GCP, Kubernetes, Font Awesome, etc.), but there wasn't a scalable workflow for maintaining or consuming them.
The initial engagement was focused on building an automated icon pipeline to automate the processing of a growing collection of SVG icons from cloud providers. What emerged was a much broader engineering effort to reduce operational friction as the product and its asset library continued to grow.
The Problem
Architecture diagrams are only as useful as the components they contain. Supporting modern cloud platforms meant maintaining thousands of icons across providers such as AWS, Azure, Google Cloud, Kubernetes, and Font Awesome.
The existing workflow relied heavily on manual processing and duplicated assets inside the application. As the catalog expanded, maintaining consistency became increasingly expensive. Updating icons required engineering effort, and introducing new providers or categories became progressively more time-consuming.
The challenge was more than simply managing SVG files: it was designing a workflow that could scale alongside the product. Client:
Building Infrastructure Instead of Features
Rather than treating icon management as a collection of scripts, I approached it as an internal platform.
I built an automated pipeline that standardized raw SVG assets, optimized them, generated typed React components, and published them as a versioned package consumed by the application. GitHub Actions handled the entire publishing process, allowing the engineering team to update the icon library through a predictable CI/CD workflow instead of manual releases.
This shifted the responsibility for maintaining icons away from the product codebase and into a reusable piece of infrastructure. The application no longer owned thousands of static assets; it depended on a versioned package with a well-defined release process.
The immediate benefit was consistency, but the longer-term value was operational. New providers, additional icon sets, and future improvements could be introduced without repeatedly touching product code.
Scaling the User Experience
As the icon catalog grew into the thousands, the bottleneck moved from asset management to discoverability.
An icon browser that performs well with a few hundred assets often becomes unusable at much larger scales. Rendering everything eagerly, relying on exact search, or forcing users through deep navigation all create unnecessary friction.
To address this, I redesigned the selection workflow around fast search and progressive exploration. Virtualized rendering kept the interface responsive regardless of catalog size, while fuzzy search and provider-based organization made large collections easier to navigate.
The technical implementation mattered, but only because it supported a better user experience: engineers could find the right component quickly without thinking about how the underlying catalog was organized.
Contributing Across the Product
As the engagement progressed, I contributed beyond the icon platform itself.
I developed frontend components, backend services, database models, and internal administration tooling supporting the broader product. This included features for managing application data, improving search capabilities, and extending the internal systems used by the team.
Working across these layers reinforced an important principle: product engineering is rarely about optimizing a single component. Decisions made in infrastructure affect developer workflows, which in turn influence product velocity and ultimately shape the experience delivered to customers.
Extending the Platform
One unexpected opportunity was using the icon catalog as a discoverable public resource.
I built a Gatsby-powered website that indexed the available cloud icons and regenerated automatically through the same CI/CD pipeline whenever the underlying library changed.
Although technically simple compared to the infrastructure behind it, this project expanded the value of the existing work by turning an internal asset repository into an SEO-focused property without introducing additional maintenance overhead.
More than an SVG pipeline
Engineering leverage often comes from connecting existing systems in useful ways rather than building entirely new ones.
At the end of the day, I'd established a reliable system that reduced manual work, separated concerns between infrastructure and product development, and allowed the engineering team to scale a rapidly growing asset library without continuously increasing operational complexity.
This project also illustrates how engineering engagements often evolve. What began as a narrowly scoped automation task became an opportunity to improve workflows across multiple repositories, contribute directly to customer-facing product development, and build infrastructure that continued to support the product long after the initial feature was complete.