How I Learned to Stop Worrying and Love Open-World Software (Or, The Breath of the Wildification of SaaS)

A few months ago, a user on a feedback call described Kasava as "insanely complex."

He didn't mean it as a compliment. He meant: I can see there's a lot here, but I have no idea where to start.

He was right. And honestly, I already knew it. I just didn't want to admit it yet.

The Problem With Building Fast

Building with AI in 2026 means you can ship features really fast, fast enough that what used to take a team of five engineers a quarter can now get prototyped in an afternoon. The bottleneck isn't implementation anymore; it's judgment.

And for a while, I had terrible judgment.

Kasava is a platform for product engineers, the people who both think about what to build and actually build it. We do a lot: repository indexing, semantic code analysis, AI chat with full codebase context, document generation, competitive intelligence, integrations with GitHub and Linear and Jira and Asana. The feature surface is genuinely large because the breadth of work required to plan, build, and ship products is large.

So I did what seemed logical: I built a UI that tried to surface all of it. Every feature got its own page, every page got a sidebar entry, and every capability got a button somewhere. The dashboard became a wall of cards, the navigation went three levels deep, and every user flow was carefully mapped out with screens for each step.

It was comprehensive, it was thorough, and it was, as my user correctly identified, insanely complex. I knew this intellectually, but I just thought our product was different. (It wasn't.)

What Zelda Taught Me About Software

In 2017, Nintendo released The Legend of Zelda: Breath of the Wild and fundamentally changed how open-world games work. Previous Zelda games were essentially linear. You entered a dungeon, found a specific tool (hookshot, boomerang, bow), and used that tool to solve the dungeon's puzzles in the one way the designers intended. One problem, one solution. Move on.

Breath of the Wild threw all of that out. Instead of giving players specific tools for specific problems, the development team, led by director Hidemaro Fujibayashi, built what they called a "chemistry engine": a set of rules governing how elements like fire, ice, water, electricity, and wind interact with objects and with each other. Wood burns when exposed to fire, metal conducts electricity, ice melts near heat, and wind pushes lightweight objects around the environment.

At GDC 2017, Fujibayashi described this as the shift from "additive design" to "multiplicative design", where "objects react to the player's action, and the objects themselves also influence each other." Instead of designing hundreds of unique puzzle solutions, they designed a small set of consistent rules and let players combine them however they wanted. The result was that the development team "on occasion observed things happen in the field that not even we, who created the game, could have imagined."

The sequel, Tears of the Kingdom, pushed this even further with Ultrahand, an ability that lets players grab objects and attach them together. Players started building things the designers never imagined: flying machines, autonomous battle robots, siege engines made of logs and fans. The game gives you components and physics, and you decide what to do with them.

Fujibayashi's advice to other designers? "You need to break conventions. You need to be creatively reckless."

And that's when it hit me: I was designing old Zelda, building linear paths through predetermined screens where every feature had one flow and the player (user) either follows my intended path or gets lost entirely.

What I should have been designing was Breath of the Wild.

Components Over Flows

The shift in my thinking was this: stop designing user flows. Start designing capabilities.

Clayton Christensen's Jobs to Be Done framework says that customers don't buy products; they "hire" them to get a job done. The key insight is that the job is what matters, not the path to completing it. If a user needs to understand the impact of a code change, it doesn't matter whether they get there through a dashboard card, a chat conversation, a notification, or a search result. What matters is that the job gets done.

The old Kasava was organized around views (the dashboard view, the repository view, the analytics view, the planning view), where each view was a destination with its own layout, its own navigation, and its own mental model that users had to internalize before they could get anything done. But no single view really solved anything well.

The new thinking is organized around capabilities (search, analyze, generate, compare, track), and these capabilities are components that can surface anywhere the user needs them. Code analysis shows up in chat responses, competitive intelligence appears in document generation context, and repository insights surface in planning workflows, all the same underlying capabilities presented wherever the user happens to be working.

In game design terms, I stopped building dungeons and started building a physics engine.

What This Looks Like in Practice

Old approach: A user wants to write a technical spec, so they navigate to the Plans section, create a plan, add a document, select a template, configure options, and hit generate. That's five screens and one prescribed path, and it assumes the user guessed the right starting point.

New approach: A user opens the AI chat and says "write me a technical spec for the authentication refactor." The chat pulls repository context (code structure, recent changes, symbol dependencies), retrieves relevant competitive intelligence and customer signals if they exist, and generates a document. If the user wants to iterate, they keep talking. If they want to formalize it into a plan, one click. If they want to export it as an agent-ready spec for Claude Code or Cursor, another click.

Same job done, no prescribed path. The user didn't need to know that Plans exist as a concept, or that we have a document generation pipeline, or that competitive intelligence feeds into specs; they just asked for what they needed and the system figured out the rest.

The capabilities are identical in both versions (code analysis, signal aggregation, document generation, plan management), but in the first version the user has to understand our information architecture to access them, while in the second they just describe what they need and the system assembles the right capabilities on their behalf.

This is the Ultrahand moment. We're not giving users a hookshot that works in one dungeon. We're giving them components that attach to each other.

The Courage to Hide Things

The hardest part of this transition wasn't technical. It was emotional.

When you've spent months building a feature, your instinct is to put it front and center. Look at this competitive intelligence dashboard! Look at this semantic code analysis! Every feature feels like it deserves a spotlight because you know how much work went into it.

But users don't care about your architecture; they care about their problems. The paradox of choice is real: more options don't help people decide; they help people leave.

We already had this philosophy in our own design system. Our core design principle is literally "Focus over features: every screen should answer one question clearly." We had codified this. We just weren't living it.

So I started hiding things, not removing them, but making them contextual instead of prominent. Capabilities that were previously top-level navigation items became things that surfaced when relevant, and features that had their own pages became components embedded in the flows where they actually mattered. The sidebar got shorter, the dashboard got simpler, and the product got less "impressive" on a feature tour but far more useful in daily work.

Open World Doesn't Mean Empty World

One important caveat: the open-world game market is valued at roughly $19 billion and growing fast, projected to reach $46 billion by 2032, but not every open-world game succeeds. Many are vast but hollow, offering giant maps with nothing meaningful to do and freedom without any real purpose. Star Wars: Outlaws got dinged for this. So did Mario Kart World.

The lesson here is that composable doesn't mean structureless. You still need good defaults, onboarding that introduces capabilities, smart suggestions for what to do next, and powerful tools that have done the work to anticipate what the user is going to want to do. What the jobs to be done are.

The Zelda Principle

If I had to distill this into a principle, it would be:

Build a chemistry engine, not a dungeon.

Dungeons are linear, prescriptive, and impressive on first playthrough. Chemistry engines are combinatorial, emergent, and get better the longer you use them.

In SaaS terms:

Design capabilities, not pages. A capability is a thing your product can do. A page is where you've decided it should live. Users care about the first one.
Let users compose. If your features can combine in useful ways, let them. Don't force people through a wizard when they could just describe what they want.
Surface contextually. The right feature at the right moment beats a comprehensive feature directory. Nobody reads the manual.
Have the courage to hide. If a feature is valuable, it'll surface when needed. If it only gets used when you put a big button on the dashboard, maybe it's not as valuable as you thought.

Our product is still complex under the hood. We still do all the things we did before. But the surface is simpler, the entry points are more natural, and the user gets to chart their own path through the capabilities we provide.

Just like Link in Hyrule. Except with fewer explosions.

Usually.

Building something and wrestling with the same complexity questions? Find me on LinkedIn.

Sources

Breath of the Wild: Experimental Solutions (Joshua Gad, Medium) - Fujibayashi's "additive to multiplicative design" concept from GDC 2017
GDC 2017: Breaking Conventions with Breath of the Wild (Thumbsticks) - Coverage of Nintendo's GDC talk on BotW's open-world design philosophy
Breath of the Wild, Science, and Clever Little Lies (Thumbsticks) - The chemistry engine design approach
Why Tears of the Kingdom's Ultrahand is its Biggest Strength (Digital Trends) - Player creativity enabled by composable tools in TotK
Know Your Customers' "Jobs to Be Done" (Harvard Business Review) - Clayton Christensen's Jobs to Be Done framework
The Paradox of Choice: Do More Options Really Tank Conversions? (CXL) - Research on choice overload effects in software and SaaS
Open World Game Market Size & Trend (Business Research Insights) - Market valued at ~$19B in 2023, projected $46B by 2032 at 10.4% CAGR