About

I'm Nick Saunders, a Lead UI Engineer specializing in React, TypeScript, and design systems. I started learning HTML in 1997. Today, I build web applications and component libraries.

Background

My professional career began with full-stack web development, from server-side logic and SQL databases to the markup, styling, and behavior that define the user experience. Early on, I worked primarily with C#, ASP.NET, and SQL Server. Over time, my focus shifted toward JavaScript and frontend architecture, eventually settling on React and TypeScript.

I began working on design systems in 2019. Since then, I've developed both product UIs and the component libraries that power them, collaborating closely with engineers, designers, and product managers to translate design intent into working software.

Building and maintaining open-source libraries has deepened my experience with API design, technical documentation, versioning, CI/CD, and release management. You can find that work on the Projects page.

I've also spent significant time studying functional programming with PureScript. In addition to producing some interesting libraries, this has shaped much of how I think about types and composition.

How I approach it

Building applications informs how I design components. A component can look elegant in isolation while lacking the flexibility required to solve real-world use cases. My approach is to provide simple, robust, and accessible solutions for common cases, while emphasizing composability for advanced scenarios.

Developer experience matters both for the consumers of a component library and for the ones who maintain it. I want to understand how a component works by reading its code, not by tracing unrelated stylesheets or figuring out which props a parent silently forwards to it. That leads me toward explicit interfaces, local reasoning, and strong type safety.

A useful abstraction hides the machinery while preserving the control its consumers need. Sometimes that means a simple prop. Sometimes it means making composition more explicit, even at the cost of a few extra lines of code. While I value conciseness, I don't assume that a terse API is a simpler one. I consider what work it saves, what it hides, and who has to deal with the tradeoffs.

Why I write

I write to share what I've learned building software—what has worked well, what hasn't, and what I wish I'd understood sooner. I want readers to question familiar approaches, including my own, rather than accept them because they're popular or convenient. Simplicity is what I value most, but a convenient shortcut doesn't always lead to the simplest solution. By working through concrete examples and making the tradeoffs explicit, I hope to help other developers think for themselves, avoid unnecessary complexity, and make decisions they can explain and stand behind.