By Ink & Switch, subtitled Restoring user agency in a world of locked-down apps
tools that users can reshape with minimal friction to suit their unique needs. Modification becomes routine, not exceptional. Adaptation happens at the point of use, not through engineering teams at distant corporations.
Citation:
Geoffrey Litt, Josh Horowitz, Peter van Hardenberg, and Todd Matthews. 2025. Malleable Software: Restoring User Agency in a World of Locked-Down Apps. Ink & Switch. https://www.inkandswitch.com/essay/malleable-software/.
Outline
Motivation
We want to adapt our environments
Mass-produced software is too rigid
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.
It may seem inevitable that our specific requirements aren’t served by our software—but that’s only because we’ve taken for granted that software is controlled by centralized development teams. What if we were to shift more control into the hands of users who know their own needs?
App stores are designed for companies distributing software to consumers, not amateurs sharing tools with their friends. This is a system of industrial mass production, not small-scale craft.
This is interesting, but it also leads me to think about what the civilizational substrate of software needs to be, in order to serve the needs of the many, and how that is in opposition to "small scale craft". The equivalent of aqueducts and sewers. Sync engines, accounts, user owned data, and encryption.
Our goal: malleable software
 Malleability isn’t a narrow technical problem.
Great phrase.
Existing approaches
Plugins
Going from installing plugins to _making_ one is a chasm that’s hard to cross. And each app has its own distinct plugin system, making it typically impossible to share plugins across different apps.
Obsidian is mentioned here.
Quote the Open Source section in full:
The open source software movement promotes the idea of distributing source code so that users of software can own their software, contribute back to it, and if needed create their own version that better meets their own needs. This has been a positive force for the world, and represents an important ingredient for malleability.
But having access to edit the code doesn’t mean minimal friction. Modifying a serious open source codebase usually requires significant expertise and effort. This applies even for making a tiny change, like changing the color of a button . Even for a skilled programmer, setting up a development environment and getting acquainted with a codebase represents enough of a hurdle that it’s not casually pursued in the moment.
I am less positive on open source, or rather the mere existence of a certain kind of license. Proto Apps, with user owned data means that as a user, I can move between apps or switch between clients regardless of their license.
AI-assisted coding
Will AI tools automatically make malleable software a reality?
There is now momentum towards a world where anyone can generate a web application from a chat, without needing any programming experience.
How can users tweak the existing tools they’ve installed, rather than just making new siloed applications? How can AI-generated tools compose with one another to build up larger workflows over shared data? And how can we let users take more direct, precise control over tweaking their software, without needing to resort to AI coding for even the tiniest change? None of these questions are addressed by products that generate a cloud-hosted application from a prompt.
Bringing AI coding tools into today’s software ecosystem is like bringing a talented sous chef to a food court. If you’re used purchasing meals from a menu, a skilled chef can’t do much to help you. Similarly, if you’re using closed-source software from an app store, an AI coding assistant can’t do very much to help you as a user. To fully take advantage of the capabilities of AI, we need to move past the food court to something more like a kitchen—a site of open-ended creation.
This essay isn’t an exhaustive survey of all work on malleability. For a longer reading list, we recommend the Malleable Systems Collective catalog.
Bookmarked! Malleable Systems Collective
A gentle slope from user to creator
Tools, not apps
So far we’ve focused on the rigidity of individual applications. But there’s another reason that it’s hard to adapt software to meet our needs: the very idea of “applications”. Because we’re so accustomed to this idea, it can be hard to see the nature of the problem—so let’s consider an analogy from the kitchen.
Apps are avocado slicers
A lot of people love this section, broke it out into it's own page: Apps Are Avocado Slicers
Aside:
A key inspiration in this area is Michel Beaudouin-Lafon’s work on Instrumental Interaction described in his talk A World Without Apps.
Sharing data between tools
Composing the user interface
Communal creation
This whole section is great
And there’s an even more fundamental reason to think of malleability through a communal lens: we use computers together! A product team needs a single system for tracking projects. A department at a hospital needs a single system for patient intake forms. These communities are certainly not well-served by one-size-fits-all applications they have no control over. But the solution can’t be every-user-for-themselves either. We should help communities build and maintain shared solutions to their problems.
See The inequities of our remote gathering tools for more on how one-size-fits-all apps like Zoom can disrupt democratic social dynamics.
With the right infrastructure, we can work together to craft our software. People with similar needs around the world can exchange work and build collaboratively, as we have seen happen in free-software communities. And local communities, from companies to families to civic organizations, can build and maintain software suited to their local needs. When local needs get higher up the “slope” and call for special levels of skill and enthusiasm, you don’t need everyone in a community to attain these levels – just enough people to play that role and get the job done.
Building software for “local” contexts is sometimes easier than building software for world-wide use. You don’t need to build airtight, industrial-grade software if you are in direct contact with your users and can be responsive to the situations they run into. You don’t need to anticipate everyone’s needs in your design, just your community’s.
On an even more intimate level, Robin Sloan memorably described how an app built for his family could be a “home-cooked meal”.
See also Home-Cooked Software and Barefoot Developers
Ink & Switch prototypes
we have been prototyping an infrastructure stack for building, running, and sharing software that prioritizes malleability. Our approach builds on another area of our research: local-first software Local-first Software Essay, which is a philosophy that prioritizes giving users ownership and control over their data, while maintaining the ability to collaborate with others. As part of that work, we developed a collaboration library called Automerge, which persists and synchronizes JSON documents among users.
Patchwork
Another thing we’ve found while customizing Patchwork is that AI is a useful complement to a malleable environment. We argued earlier that AI-assisted coding alone does not guarantee malleability. But when combined with a malleable environment, AI-assisted development can make it much faster to edit your tools.
We’ve used AI assistance to rapidly build many tools in Patchwork. The Section Word Counter tool mentioned above was coded with AI assistance in just a few minutes—in the middle of a writing session, without needing to set aside dedicated time.
A malleable environment can also provide platform capabilities that make AI-generated software more useful. For example: we have an interface for making small software tools from an AI chat. While this UI superficially resembles existing products like Claude Artifacts, the generated tools gain capabilities from existing inside of Patchwork. They automatically support persistence and multi-user collaboration, and can compose with existing tools for editing existing data.
A related challenge is managing expectations of quality. Most of the tools we’ve built aren’t anywhere close to the polish level of commercial products; they’re scrappy personal tools. When someone shares a tool, how can they communicate its level of quality? There’s a difference between sharing a tool “as-is” and committing to ongoing maintenance.
Infrastructure for malleability
Dynamic documents
Towards a better future
Big challenges ahead:
Privacy and security: How do we reconcile the desire for extensible software and interoperability with the reality of bad actors? When untrusted strangers are sharing modifications to existing software that can access sensitive data, dangerous things can happen.
Business models: How would developers make money from their software if they were shipping composable tools, not monolithic applications? How is support and maintenance paid for?
Culture: How do we cultivate a movement towards personal agency where people want to modify their environments, both digital and otherwise?
These are daunting challenges. Technical capabilities can’t be a full solution; economic and cultural shifts will also be required. But change is possible—computing is still young, it has changed a lot in the past decades, and surely many structural shifts still lie ahead.
Everyone deserves the right to evolve their digital environments. It’s an important way to fulfill our creative potential and maintain a sense of agency in a world that is increasingly defined in code.