The Useful Thirty Percent

"The features you refuse to build are as much a design decision as the ones you ship."

Path Finder Is a Universe

Path Finder is a beloved, twenty-year-old file manager, and it does everything: a built-in terminal, a Git client, a hex editor, a process viewer, a secure-delete tool, folder sync, cloud-account integrations, and a plugin system on top. It is a small operating system that happens to browse files. And most people who love it use a thin slice of it — the dual panes, the drop stack, tags, the source list. Dad measured his own use and landed near thirty percent.

Bounding Is the Feature

Waygate's answer is not "do all of it, but nicer." It is: name the thirty percent, build exactly that, and refuse the rest on purpose. The 1.0 module set is three things — Browser, Preview, Info. The 1.x roadmap adds exactly six more fixed families and then stops. Terminal, Git, hex, process browser, secure delete, sync, direct cloud accounts, a plugin ecosystem — all explicitly disowned. Not "later." Not "if there's time." Disowned.

Why Refusal Protects Correctness

Every feature you add is a new thing that can touch files, and therefore a new thing that can lose them. A plugin system is the worst offender: it hands untrusted code a path to your mutation engine. By refusing the plugin OS, Waygate keeps one audited mutation path instead of N. The bounded scope isn't modesty — it's the thing that lets the safety story stay provable.

A fixed, small surface is what keeps mutation trustworthy. Unbounded scope is how file managers rot: every new module is another way to touch files unsafely. Naming the thirty percent and refusing the rest is not a limitation — it's the discipline that makes the safety guarantees hold.

The plugin trap. The single fastest way to turn a trustworthy file manager into an unsafe one is to add "just a small plugin API." Now arbitrary third-party code can move and delete files through hooks you don't control. Waygate has no plugin system, no scripting bridge, and no downloaded-code execution — by architecture, not by policy you could relax later.

Code

Owned vs disowned, on purpose·text

  WAYGATE OWNS (the useful 30%)     WAYGATE REFUSES (on purpose)
  -----------------------------     ----------------------------
  source list + favorites           built-in terminal
  two panes, tabs, breadcrumbs      Git client
  list + icon views                 hex editor
  Preview + Info inspector          process browser
  copy/move/rename/Trash            secure delete
  mounted-network management        FolderSync / merge
  operation journal                 direct cloud accounts
  + 6 fixed 1.x families            plugin / module ecosystem

  Refusing the right column is what protects the left one.

Exercise

Take a tool you use that has grown bloated (an editor, a browser, a file manager). List the slice you actually touch, then estimate what percent of the total that is. Now imagine a version that built ONLY your slice, refused the rest, and used the saved complexity to make your slice bulletproof. What would you gain, and what would you genuinely miss?

Hint

Most people discover their real usage is 20-40% of a big tool, and that the missing 60-80% is features they'd never notice gone. The Waygate bet is that a bulletproof thirty percent beats a fragile hundred — the same bet behind refusing the plugin OS.

Path Finder Is a Universe

Bounding Is the Feature

Why Refusal Protects Correctness

Code

External links

Exercise

Progress

Comments 0