Tooling migrations don't have to take weeks anymore
I used to block out weeks for tooling migrations. Now I let Claude Code run in the background, check in when it's done, and pair with it to understand what changed.
Design systems are exploding in popularity across the industry. IBM, Google, Uber, Shopify, and Atlassian all have them. Smaller, pre-IPO companies are beginning to wonder whether they need to get in on the action. But let's talk about what a design system actually is before we decide whether or not your company should invest in one.
A design system is a set of rules, documentation, processes, and encoded decisions that guide the creation of one or more applications.
If a company has a website, it already has a design system. Unfortunately, if no one has actively cultivated that it, it's probably a really, really ineffective design system.
A good design system improves collaboration between designers and developers and speeds up development while improving quality in the long-term. At a bare minimum, it requires three key components to achieve these goals:
As a design system scales, each of these components can increase in scope and complexity. For example, if a company only has one web application, it's OK for the code to live inside of that application. But once the system needs to support two or more web applications, it's better to extract the code into a separate library where it can be shared.
I used to block out weeks for tooling migrations. Now I let Claude Code run in the background, check in when it's done, and pair with it to understand what changed.
Frontend technical debt doesn't just slow down developers. It undermines your entire business through user attrition, legal risks, and revenue loss. Here's how to spot and communicate these hidden costs.
How I used Conductor and Claude to streamline my team's Dependabot review workflow — and how a colleague turned it into a GitHub Action