One of the easiest ways to explain malleable software is to compare it with something the software industry already understands well: configurable software.
The industry solved configuration a long time ago. Most CTOs are familiar with the idea of exposing settings or feature flags so customers can tailor a product to their needs. We decide upfront what options users might want, build those options into the product, and then expose them through configuration screens.
Even products that take configuration to an extreme are still operating within those predefined boundaries. A good example is feature flags. Products like Linear allow customers to enable or disable functionality, but those features were still designed, built, and anticipated by the vendor. The customer is choosing from a list of possibilities that already exist.
Malleable software works the other way round. You're no longer trying to predict every permutation your customers might require. Instead, you're giving them the tools to build the thing they need, even if you never anticipated it.
A dashboard is probably the clearest example. In a configurable dashboard, the vendor provides a collection of widgets. Users can rearrange them, choose which ones to display, and perhaps configure a handful of options. Every widget has been designed, implemented, and tested by the vendor ahead of time.
A malleable dashboard starts from a different assumption. Instead of asking, "Which widgets should we build?", you're asking, "What capabilities should we expose so customers can build the dashboards they need?"
Imagine a customer wants a Marimekko chart. Perhaps no other customer will ever ask for one. In a configurable product, that request ends up on the roadmap, where someone has to decide whether it's worth building for everyone.
In a malleable product, the customer simply asks for the chart and the system creates it. The vendor never had to anticipate that requirement.
In fact, once you start thinking this way, there's no reason to stop at individual widgets. The entire dashboard can become malleable. Instead of assembling dashboards from predefined building blocks, users describe the dashboard they want and AI constructs it using the data and capabilities the product already exposes.
The same applies to imports and exports. Today, SaaS products usually provide a handful of export formats because that's all the vendor had time to build. But customers frequently want slightly different formats because they're integrating with another internal system or another SaaS product. Rather than continuously adding new export options, a malleable product lets customers define the exact export they need.
None of this means you should configure less. Configuration still has an important role. The two approaches just draw the boundary in different places.
With configurable software, the vendor is confident in every individual feature they've built.
With malleable software, the vendor is confident in the underlying capabilities they've exposed.
You're no longer thinking about individual screens or widgets. You're thinking about the primitives users can combine to create solutions you never designed yourself.
This becomes particularly valuable as SaaS companies grow. Almost every growing SaaS company eventually reaches a point where larger customers begin influencing the roadmap. Those customers often have highly specific reporting requirements, import requirements, export requirements, or bespoke workflows that don't apply to anyone else.
Reporting screens are a classic example. They become a bottleneck because every enterprise customer wants something slightly different. Traditionally, every one of those requests competes for engineering time.
With a malleable product, the goal isn't necessarily to let end users build everything themselves. Instead, you're giving customer success teams, sales engineers, product teams, or technically capable customers the tools to satisfy those bespoke requirements without needing engineering to build every feature directly into the product.
The question changes from, "Should we build this feature?" to, "Do we already expose enough capability for someone to build it?" Teams that make that switch start planning their roadmap differently.
The obvious question is: why now? Mostly, the technology changed. Five years ago, this simply wasn't possible. AI models weren't capable of reliably generating rich user interfaces or product features from a single prompt.
Even over the last few months we've seen a significant improvement. The latest generation of models has become dramatically better at producing complete features in one shot, rather than requiring long back-and-forth conversations. That change alone makes malleable software substantially more practical than it was even six months ago. The models are what make this category viable now.
There has also been a cultural shift. People are now comfortable interacting with AI. Whether it's end users or internal product teams, chat interfaces have become familiar. Plenty of people have already experimented with products like Lovable or Replit and understand that AI can build useful software from natural language. That familiarity makes introducing malleable software much less confronting than it would have been a few years ago.
That doesn't mean every application should become completely malleable. In fact, I don't think users want fully malleable products.
Good product decisions still matter. Research still matters. Opinionated design still matters. Most users don't want to design an entire product from scratch.
Vendors win in the final 10%.
It's about closing the feature gap that would otherwise require engineering time. It's about landing an enterprise customer whose only blocker is one missing report. It's about allowing products to stretch just enough to meet individual customer requirements without forcing vendors to permanently expand the product for everyone else.
That's where malleable software becomes compelling.