What makes software malleable?
Malleability isn't a single feature you can point at. It's a handful of properties that tend to travel together.
- The person who needs the change is the one who makes it. It doesn't have to go through a vendor engineer, a systems integrator, or a ticket in someone else's backlog.
- The change adds capability, not just preference. A new view, a new field, a new automation, a new panel: something that wasn't there before.
- It happens in the product, on live data. Nobody has to export to a spreadsheet or rebuild the workflow somewhere else.
- It's reversible. If what you built isn't right, you can throw it away and the product is exactly as it was.
How is malleable software different from configuration?
This is the line most products blur. Settings pages, themes, dark mode, notification preferences, drag-to-rearrange dashboards: none of these make software malleable. That's configuration, which is helpful, but still a set of choices the vendor decided on ahead of time.
A useful test: if the vendor could have listed every possible outcome in a dropdown, it's configuration. If the person using it can build something the vendor never anticipated, it's malleable.
It comes down to whether the vendor had to imagine your case in advance. A menu, however long, was written by somebody who was guessing at what you might need.
Customisation sits somewhere between the two. When a vendor offers customisation, they usually mean that they will make the change for you, for a fee and on their timeline. With malleable software you can make that change yourself, when you need it, rather than waiting on a quote or a place in the roadmap.
How is malleable software different from low-code and no-code?
Low-code and no-code platforms are places you go. You leave the software you use all day, open a builder, and assemble a new app beside it. From then on, the integration, the auth, the data sync and the maintenance are all yours to look after.
Malleable software works the other way around, because the surface is built in. The change happens inside the product you're already using, against the data that's already there, under the permissions you already have. Nobody has to wire up an API or keep two systems in step.
The distinction blurs at the edges. Airtable is a no-code platform, and it also has a deeply malleable surface sitting on data its own users defined. Retool and Bubble are builders whose output is a separate app, which is why they don't appear in our directory. The questions we keep coming back to are who makes the change, where it lands, and whether the person doing it had to become a specialist first.
Why does malleable software matter?
Every product does most of what a customer needs and misses the rest. The missing part is rarely one big feature. It's a thousand small ones: a report shaped a particular way, a field that only your industry uses, a rule that matters at your company and nowhere else.
No roadmap can absorb all of that. Taken one at a time, each request is too small to prioritise. Taken together, they are far too large to ship. So they sit in a queue. Sales hears them, Support does its best with them, and Product rarely has the room to build them.
Malleable software hands that last stretch to the people who understand it best, who are almost always the people doing the work. Ink & Switch, whose June 2025 essay put the term into wide use, frame it as restoring user agency in a world of locked-down apps, and argue that people should be able to adapt their tools to their own needs with very little friction.
Where does the idea come from?
Researchers have been studying tailorable software and end-user development since the 1990s, mostly asking the same question: why do the people who understand a problem have no way to change the software that handles it?
- Litt, Horowitz, van Hardenberg and Matthews, Malleable Software: Restoring User Agency in a World of Locked-Down Apps (Ink & Switch, June 2025). The essay that gave the category its current name.
- Lieberman, Paternò and Wulf, End-User Development (2005). The research field's own introduction, and the case that a computer should be a set of capabilities shaped to the user's needs rather than a fixed appliance.
- Clay Shirky, Situated Software (2004). On why software built for a small, known group can beat software built for everyone.
- End-user programming. The older research tradition the idea grows out of, and how it differs.