A Year of Decisions at Knapsack

Last year, I made the decision to join Knapsack, a design systems startup, as a Staff Engineer.

"You did WHAT?"

Is the first comment I get from friends and folks in my network. I get it ! I was "fiercely independent" for about a decade. Building startups and consulting with amazing record labels, game devs and other non-enterprise folk.

Well here's my summary: I went looking for the AI-native action, and found that – in three different ways – everywhere I expected the action to be, it had already moved: from the delivery surface to the decision surface.

What I came for

Before making the move, I saw something shifting in my clients' organizations. Decisions felt harder to make, harder to maintain and harder to keep pace with. Decision-making was overtaking building as the bottleneck.

In 2025, after a year pitching hard on AI enablement and doing 0-1 builds for clients, I wanted to be somewhere already bought in. I had been investing in and pitching RAG systems, Evals loops, MCP connectors and modernized LLM-tooling, however, most clients simply didn't have the appetite. I could either make the leap into client pipeline redevelopment, or embed myself into a team.

Design systems have been on my radar since 2018 when I had worked on a large-scale effort for a health insurance provider out here in Oregon. The value of design systems had followed me as I went to work with startups that were hungry for ways to deliver faster. The concept of investing in a pre-made set of design decisions was attractive, but few could afford the investment, let alone had the right staff to deliver on it.

Knapsack builds specifically for enterprise design systems. When a friend pointed me to their need for an AI systems builder, I followed up and was pleasantly impressed with the team. I had known their co-founders through the grapevine for years and this would be a chance to officially team up.

So, after talking with the smart folks on the Knapsack team, it seemed like a great fit. I came in with a personal list – ship AI products, join the design systems dialogue, learn the Series A from the inside, sharpen enterprise sales – and looking back, I hit my marks.

But my growth wasn't constrained to the list. There were three primary things that changed my thinking that turned out to be very different than my expectations.

I thought AI's job was to build faster

Just like most innovative Engineers, I had an initial ramp up with AI: - 2023: Copilot, langchain & Simon Willison's llm package - 2024: Aider & RAG system - 2025: Claude-code & MCP

I brought Cursor into my clients' teams and built & encouraged PR auto-reviewers. As I joined a larger team as a member, I expected that we'd ramp up both quality and velocity. No more pick-two: "speed, quality, cheap". Instead: pick-three !

In reality, being able to ship 10k-line PRs overnight creates more work than value. And shipping code, design, docs or even features is not shorthand for creating value.

If you can ship anything, capabilities are not nearly as important as cohesion. What matters are the decisions you make – what to build and for whom – that you can stand behind, and that you measure.

This is not easy, it never has been – but the rate at which strong, cohesive, strategic decision making is required has increased exponentially. Strategic demand is at an all time high, but most of us have been building for a tactical day-to-day.

The bottleneck is the planning, not the execution.

(It's also not the "spec" – it's the OODA loop, the observe–orient–decide–act cycle, that arrives at a spec.)

If AI's job is to build faster, your job, to decide what to build, becomes all the more important. The action moved from delivery to the decision of what to build.

I thought the asset was the value

For the last 10 years, design system momentum has all been about "publishing" your design system – the shared components, tokens and rules an organization builds its interfaces from. Getting the buy-in, collecting the components, writing docs – the end goal is hitting publish on your site and declaring you're open for business to the rest of the org.

This, turns out, wasn't the same as design system success: it was 'design system documentation' success.

Adoption, the hard part, had only begun.

Coming from a world of product building, this felt familiar. There's a ton of energy around landing on Product Hunt, sure, but landing 1000 signups is just the start of a long haul for MRR.

Design systems illustrated an old problem, in a new way. It's not enough to deliver output, your delivery has to meet people where they are at and help them get what they need.

The real asset isn't the documentation, it's the ongoing development of the system – responding to customer needs, and delivering the system straight into their workflows as the technology makes new ways possible. The action moved from delivering the system to adoption – which is a decision, made by every team, every day.

I thought design systems were the boring end of frontend

Here's what's been delightful.

I came in thinking design systems were on the "blah" end of design.

When you think about Apple awards or Webbys or websites you send to friends (dating myself here), what catches your eye?

Those animations... those motion effects... that parallax...

Sorry folks, that's never due to the design system.

Design systems intentionally handle the mundane, thorny, and complicated parts so that others can build from a confident, common foundation.

So, are they intentionally boring? Often times, yes.

But this foundation-setting is where the action is.

When you turn design into a system, well-documented and distributable - amazing things happen. You can send that system anywhere, to be used for purposes you previously hadn't even considered. Suddenly marketers are building websites themselves, engineers are writing decks. Down is up, up is down !

And the innovation in this field is community-driven and rich. It's happening at every layer. Design tokens, context carrying methods, interchange formats, package distribution & coded-solutions, tooling.

It's craft, process, theory and tooling – all in conversation at once. And the people behind it are brilliant and – even better – humble inventors, to the last one.

It's incredible to be in a field where the commonality is that these folks find a need, and fill it (as opposed to scratching their own itch). That's the very definition of entrepreneurial invention that my MKTG 101 professor instilled in me back in college – but so rare to see it actually play out.

The exciting action moved from the surface to the foundation. From delivering the effect to deciding the toolkit, for everyone.

Delivery demands hid decision demand

My father-in-law once told me: "Electricity has always been here, it just took humans a long time to learn to harness it".

So: maybe nothing moved, and we just moved closer to the important action. Planning was always the bottleneck; adoption was always the hard part; the foundation was always where the leverage lived.

I'll take that. For those of us building things in the last decades, focus on delivery seemed to absorb our attention not because it was the most important thing but because it was the most pressing thing.

It used to be that making one strategic decision gave your delivery engine enough gas to drive on for a whole month. Today, those ratios have changed, and what was hidden behind the pile of delivery is now more visible than ever.

A year of system design in design systems

The thing I'm most grateful for is how Knapsack's given me the opportunity to explore and contribute with some of the sharpest system design folks I've had the opportunity to work with.

If you've known me in the last 20 years, you know I'm deeply passionate about equipping creators and entrepreneurs to make – whether that's musicians, gamedevs, authors or artists.

Being so involved with folks doing that work inside of enterprises has given me a new appreciation for what it's like to be the internal entrepreneur inside of companies who need to design at scale, and keep up with an ever shifting landscape.

So, to everyone who asked: I went to uncover decision frameworks, and learned that the AI revolution has inverted decision demand.

We need more decisions, we need them to be durable, and we need them faster than ever.