Malleable Software

Essay, Ink & Switch, June 2025. By Geoffrey Litt, Josh Horowitz, Peter van Hardenberg and Todd Matthews. Subtitle: “Restoring user agency in a world of locked-down apps.” Part of Ink & Switch’s Tenfold tenth-anniversary series.

Key Takeaways

• The framing analogy is physical space. A guitar maker arranges their workshop; a home cook installs hooks and moves shelves. “In the physical world, the act of crafting our environments comes naturally, because physical reality is malleable.” Software environments are where we now live, and they are not.
• The index-card story is the whole argument in miniature. A team tracked work with cards taped to a wall, constantly evolving the process — tape lines moved, checklists appeared, special zones emerged. Moving to a web issue tracker killed the special zone, and then killed further process change: “Before, new ideas took minutes to try; now they could take hours of wrangling configurations, if they were possible at all. Computerizing work led to a loss of agency.”
• Rigidity is a real harm, not an annoyance. Citing Atul Gawande on physician burnout: doctors once skipped irrelevant fields on paper forms and now cannot. Of one doctor: “Spending the extra time didn’t anger her. The pointlessness of it did.” The counter-story is the neurosurgeon who worked with an IT analyst to build a department-specific records interface — faster, more intuitive, and an antidote to burnout.
• The definition: “a software ecosystem where anyone can adapt their tools to their needs with minimal friction” — with each word load-bearing. “Minimal friction” is the one most often skipped: editing your tools should be light enough to do in the moment.
• Existing approaches each fall short. Settings only expose what developers anticipated. Plugins only edit in authorized ways, and “going from installing plugins to making one is a chasm that’s hard to cross.” Mods work without permission but require reverse-engineering and break on updates. Open source gives you the code but not low friction — even changing a button’s colour means setting up a dev environment.
• AI codegen is necessary, not sufficient. “Bringing AI coding tools into today’s software ecosystem is like bringing a talented sous chef to a food court.” Even granting perfect code generation, it leaves open: how do you tweak tools you already have rather than making new silos; how do generated tools compose over shared data; and how do you make tiny changes without invoking an LLM at all.

The three design patterns

1. A gentle slope from user to creator. From MacLean et al.’s 1990 User-Tailorable Systems: Pressing the Issues with Buttons: plot customization depth against required skill, and a “cliff” is anywhere the next increment of power demands a large jump in learning. The design goal is that each increment of tailoring power costs only a small increment of skill. Spreadsheets are the canonical gentle slope — an in-place toolchain (everyone running the file is running the full editor) plus a scrappy aesthetic that makes editing feel safe. HyperCard did it with explicit levels, 1 (read-only) through 5 (HyperTalk scripting). Notably, the essay argues you can flatten a cliff from either end — making programming more approachable, or starting from a media editor and adding optional programmability, the pattern shared by spreadsheets, HyperCard, Flash, Notion and Airtable.
2. Tools, not apps — “apps are avocado slicers.” A 3-in-1 avocado gadget needs no practice and does exactly one thing; a knife requires skill and does everything. Most applications bundle functionality around a use case, handle none of it especially well, and can’t be coordinated beyond window-tiling and copy-paste. Text editors and spreadsheets are the knife-like exceptions.
3. Shared data and a shared workspace. Composability needs tools operating on one shared reality — the desktop filesystem is the well-known case (edit the same photo in Lightroom then Preview; the same repo in VSCode and emacs), and the essay argues the missing ingredient today is a modern filesystem equivalent with real collaboration support. Airtable/Notion show multiple views over one database; Smalltalk shows shared objects with behaviour, not just inert data; Webstrates shows two people editing one paper live in two different editors.

Connections

• This is the intellectual backbone of Kyle’s Modularization of Software draft — and it arrived in his notes as “From Branick”, alongside a Diagonal deck making a strictly commercial version of the same argument (a “personalized software era” succeeding horizontal and vertical SaaS). The essay is the rigorous statement; the deck is the go-to-market.
• The “apps are avocado slicers” section is the cleanest available argument for why Vertical SaaS hits a ceiling: one-size-per-vertical is still one size.
• Stewart Brand’s How Buildings Learn is quoted twice — “Age plus adaptivity is what makes a building come to be loved” and, on shabby buildings, “Any change is likely to be an improvement… Do what you want. The place can’t get much worse anyway.” That second one is a design principle about polish deterring modification.
• Ties to No-Code, Tools For Thought, and Alan Kay’s software-as-clay framing from his 1984 Computer Software article.

Notes

• Reading capture is a substantial summary with verbatim quotes, not the full essay — the piece runs long and is stably hosted by Ink & Switch. Direct quotes above are verbatim; section structure follows the original.
• The essay points onward to the Malleable Systems Collective catalog for a fuller reading list.