At the most basic level, what is malleable software?

The best way to explain malleable software is to compare it to traditionally built software. Traditionally built software is like buying a product off a shelf. You have a well thought through, packaged product that does what it says, and you buy it. The idea is that you deploy that product and it does everything you need.

Now, the reality of this is quite far from that. Normally what happens is the product you're using is a compromise, because they have to make a product that fits as many people as they possibly can. So there's normally some sort of compromise that takes place, and you have to suffer those compromises yourself.

Malleable software tries to close this gap by letting you, as the user, shape the product a little bit more at the end and get a customer experience that fits your use case better.

Who is doing the shaping, and how?

There's been a concept of customisable software for a while, and it usually involves someone called a sales engineer, or maybe just your engineering team in general. Their job is to shape software. They take your requirements and try to fit those requirements to what you want. Now this is a tough thing, because it involves adding code.

What modern malleable software aims to achieve is the idea that customising the software doesn't require so much burden. This means the end user can modify the software themselves. It also means your sales engineer can modify the software for you, or a salesperson can modify the software for you.

What AI is great at is taking natural language and translating it into something like code. That has previously been the domain of someone like a sales engineer, but now lots of other people involved in that process can do it, either for you or you can do it yourself.

Is this just no-code with a new coat of paint?

There's a few different ways that it's different. The first is that no-code and low-code builders still require a certain level of competency. And we can see this by just who uses low or no-code builders. They're not normally used by end users, or even salespeople, because they have to learn some esoteric low or no-code framework in order to understand what's going on. And so they basically have to go through pretty intense training anyway, and it's almost like creating pseudo programmers to solve needs.

More on this in the enterprise feature request problem.

What stops products from becoming chaos?

We have an article about this, which is our article on guardrails and safety. But in brief, the reason you would use a platform like Rough is for exactly these reasons: to keep things contained, to keep the malleability contained to a specific surface, so that you aren't having to think through every permutation of things that a person could possibly build.

As long as you're using either a framework or a platform like ours, you shouldn't have to worry too much about users doing anything particularly dangerous. If you're interested in this, you should go read our post on safety and guardrails.

Why now?

Malleable software has always been possible, especially for highly technical users. You could argue that many different programming environments, especially open source programming environments, are malleable, because the users of those environments are technical enough to modify them themselves. You could also argue that something like Excel is extremely malleable, because you can build extremely complicated things in Excel, provided you're technical enough. So under a certain definition, malleable software has existed for quite some time.

The only difference now is that we're able to create a lot more products that are malleable. The reason we're able to do that is AI. One of the big unlocks that AI gives us is the ability to translate natural language into code. That is the main shift that's taken place over the last year, where it's really become good at this, and that has allowed products to become significantly more valuable, when previously it was only technical people that could do so.

Where did the idea come from?

I first heard about Malleable Software last year on Ink & Switch's blog. It's a simple idea: what if users could change their software?

I completely fell in love with the concept. It feels like the right to repair but for software.