Is customization bad? What about config?
They're not bad. They're definitely still good options. But now there's maybe a third option.
The first way that a vendor can deal with specific requests from customers is they can put configuration options in place. That is, you're using a traditional piece of software, and that traditional piece of software might have a settings screen. Let's say, for the sake of argument, you want to change the theme of the product. The settings screen would provide you ways to change that theme. That's great. We're all familiar with that.
The next one is something an enterprise customer will be more familiar with. An enterprise customer may request something that is very bespoke. Instead of a theme, they may want large parts of the app removed, or completely different things added to the app, in order for them to use it. So the vendor is faced with a pretty difficult decision here, because as soon as they give custom code to a given customer, they are then on the hook for maintaining that code. And as those diverge, and as you get more and more enterprise customers, that becomes a real difficulty.
So those are the two options that have been in place for quite a while now. And malleable software gives you a third option, which is a way to change the software that we use without changing the code. So we still get one specific piece of software that we're maintaining. And because we're working with specific surfaces within that software, we know the boundaries where somebody is going to be changing the software themselves. So the enterprise customer can still be happy, and you're not creating an entirely different environment for you to have to maintain.
So what's the actual difference?
The key difference between configuration and malleability is "known." The known aspect of configuration.
Configuration is you, as a vendor, predicting all of the different things that you think somebody will want to change in your software. Malleable software is you saying, I don't know all of the different things that a person may want to change in my software. So what I'm going to do is give a set of tools or capabilities, and within that set of capabilities, the person can do whatever they want, as long as it stays within this pretty loose boundary that I've defined.
So, yes, if you have an extremely strict boundary that you've defined, it might look closer to configuration. But as you broaden that boundary, you would not be able to predict all the different things that people could do with the capabilities that you've given them.
What actually holds this boundary in place?
There are a few different answers to this.
The first thing is that the model Rough works under is what we call UI sandboxing. We provide basically a black box, and you know all of the inputs and all of the outputs to that black box. As long as you're comfortable with your inputs and outputs, there's very little that can go wrong inside that box, because it's not affecting anything in the broader app. So that's one answer to it. Yes, if you try to do malleable software yourself, there are lots of different ways it can be dangerous. But this is our domain. We're very comfortable with the decisions we've made here, that they are safe for vendors to implement and put in front of their users.
But the second part of this is that it doesn't work without visibility. It's a bit of a nightmare if you think about it. You have a piece of software, you have ten thousand customers, and each one of these customers is going to shape the software in some minor way to fit their needs. You need to have visibility on that. You need some sort of analytics to understand, are these things being used? You need reporting. You need product management tools. So we provide that kind of stuff through Rough as well, and that's the other side of it.
You're actually going to know what features are being built, how much they're being used, and how much they're costing you, which is very important, because these things aren't free. They use tokens, and you can also build features that use AI, so that could be an ongoing cost. Without this visibility, yes, I think you would be kept up at night, because you would not know what is out there. But through Rough, you have the ability to see what's out there and to understand it.
What's the one thing that makes ten thousand custom variations just as maintainable as one?
Even with this new world of AI, there is still an enormous cost to owning ten thousand different forks of one code base. It's unthinkable. I don't actually know of a code base outside of open source software where that would even be possible. Even in the new world of AI, it's just not possible to maintain that number of individual pieces of software.
So take a more realistic number, like a hundred or two hundred specific instances of the same software, and then compare that to ten thousand unique features. The malleable angle still wins, because with ten thousand unique features on a malleable product, you're still maintaining one product.
So all you're thinking about is: are the contracts I'm giving to my surfaces reliable? Are we changing anything between releases that might affect the ability for people to build things into their surfaces? Do we need to think about expanding capabilities, or rejecting capabilities? What are people actually building, and is that in line with our product strategy? These are the kinds of questions we're asking.
We're not thinking, oh no, iteration number one hundred and sixty-five has a specific error with their specific way of doing things, and we can't update it because it collided with the latest branch. All of these problems that nobody wants to deal with, we avoid. And yes, it comes with a bunch of really new, interesting signals that we didn't have before. Yes, we do have to look at those signals. But they're much better signals than just, oh no, we need to maintain more code.