Software Solution Efficiency Curve

With every frontier model release, there's inevitably a plot showing how token-efficient the model is while solving a given problem or benchmark / eval.

Interestingly, the same solution efficiency curve has always applied to software, except most software solutions are incredibly inefficient, taking very long paths toward suboptimal solutions. Until recently, we haven't had control over improving that.

In the future, having the shortest path toward solving problems unique to you, the individual (rather than every company under the sun), will be how we measure success in a world where software is hyper-personalized.

Like any path-finding optimization problem, it won't be enough to be token efficient if that means a user having the same problem over and over keeps having to generate thousands of tokens for each solve.

Instead, software itself will just be a way to cache tokens and therefore optimize and shorten the pathways toward a solution.

Building for Companies

Historically, commercialized software has always been built to support many unique companies using a singular software package. This meant boiling an ocean of unique needs down into the least common denominator of what every customer hopefully shared in terms of problems and solutions.

Think about software like Salesforce, Granola, Slack, even somewhat malleable software like Notion. It's meant to be a one-solution-fits-all deliverable, which means a company of hundreds or thousands of people all hit many compromises and papercuts; or worse: we get so little value out of it after initially hoping it'd finally be "the one" we fall in love with that we end up having to painfully migrate away after convincing our entire company to join.

Building for Teams

When Retool came along, we ended up moving exclusively from Building for Companies to at least have the option of Building for Teams where internal tools could be built and customized depending on which team within a given company had unique needs.

Instead of competing with (and losing to) what the entire company needed, a team could finally solve its own unique problems.

Solutions started to feel more like a meritocracy.

Building for Individuals

When site builders like Webflow came out, it meant we could begin to build N=1 solutions, or Building for Individuals, where my outcome or solution didn't need to look like your outcome or solution.

Importantly, this was also one of the first times people trusted publishing outcomes into the wild without caring how the underlying code looked, similar to how more people are pushing LLM-written code into production without manually reviewing every line themselves these days.

As long as the solution worked for the individual, they didn't need to care about the implementation. Do you care how machine code is generated for iOS apps you use? Probably not.

It was one of the first times individuals could actually be individuals and express themselves. My canvas didn't need to look like yours. My materials could be different, me-shaped.

My solution was optimized for me, not for my company, or my coworker or even my spouse.

Shortest Solution Paths

When working on or managing teams, you inherently realize you can't tell individuals how to solve every problem. Everyone who is great at what they do comes up with their special sauce of what makes them great; ideally, all you need to do is trust them to be great at delivering an outcome.

You measure the outcome, you don't really measure the work or the "how" (unless it's truly resource inefficient, but even that's allowable in research settings).

This is what defines us as individuals. We each do things our own ways. The shape of your solution is not the shape of mine, even though we may have some Venn diagram of overlap. What makes great individuals great is often in the little details that compound over time to unlock new solutions.

Notice how no sci-fi movie has an AI that says "Sorry Hal, I can't do that because I'm limited to only delivering solutions that appeal to 8 billion other people." We all know that would be a horrible future, because that's the present and the past. An ideal future is always better.

As tokens become as available as electricity and software is increasingly personalized, we'll move from forcing monoliths onto individuals and find a you-shaped solution to every problem in your life.

That solution will be the shortest path possible, because it will solve your problem your way. No bloat, no papercuts.

Malleable Software

In order to build a future for individuals, we need truly malleable software at all levels: on the operating system, on desktop, on mobile, on the web. Sure we might share a lot of primitives or core experiences, but when it comes down to your needs and your life, software will need to reorganize it around what your problems are.

Every line of code should have to fight for survival. Evolution has always driven us in this same direction, so why should software (and even hardware one day) be any different? Everything should evolve and earn the right to survive by being of value. If it's not valuable, it should be pruned out of existence.

This is why Moldable is being built as a malleable canvas to create any app or automation imaginable. It's a forcing function to help people see the future before it's here and evenly distributed; before we have operating system orchestration layers, or XPC/RPC functions for each app to call into and share functionality or data, or AI chat unified across all apps.

Moldable is a sort of operating system for your life.

Malleable Internet

But what if the entire internet was moldable? What if I asked your website to change itself toward my needs as a customer and it immediately did so. And when my needs changed in the future, I asked it again and it did so again. How valuable would that be to the customer, and the economy?

Customers could avoid having to migrate every time they outgrow a solution. When companies, teams, or individuals change, the solution could change with them.

This will require us to rethink what we know software to be today, and how we build it. We'll need new dev frameworks, new storage mechanisms, and new UX/UI patterns.

Malleable World

This change will usher in a new way of living and interacting with the world. We'll be able to push on the world and have it flex to our needs in a way we never imagined before.

Beyond malleable software, we'll one day be able to create malleable hardware. Think about having a car uniquely designed for you or your family. Or a phone that is as simple or as complex as you need it to be.

We're entering the Age of Expression where anything is possible as long as it can be imagined or felt. Your needs matter and your voice should be heard.

You are a creator, we just need to build you a better canvas.