Can you build Retool inside of Retool?

Can you build Retool inside of Retool?
Self-hosting is when a tool can be used to build or improve itself, embodying a powerful concept in programming and software development.

One of my favorite concepts from programming language design is known as self-hosting.

Imagine you're the creator of a programming language and you're working on the next big version. What tool do you use to build that? Well, can you just use the language itself?

💡
If a programming language is self-hosted, it can be used to make future versions of the language itself.

Not all languages are self-hosted, but many of the most popular languages are: Typescript, Go, Rust, or Python. Some languages even start without being self hosted, and then become self hosted.

Neo "self hosting"

The bounds of low code tools

I'm a huge fan of the explosion in low code and no code tools over the past decade. Webflow, Retool, Bubble, Builder, Glide, <insert-your-favorite-tool-here>

All of them ushered in a meaningful democratization of who and how software can be made. Even as a developer, I often use them for one off tasks to save time.

But when I use them, I can't shake one feeling: I couldn't build them in them. They're not self-hosting.

So what would a self hosted tool look like?

I started Create to give more people the power of software creation - not just another low code tool, but the raw power of building with a programming language.

It's an AI powered product builder that lets you use English to build sites, apps, and tools. You describe what you want and Create outputs the code for it.

Recently, we launched a new ChatGPT integration. It enables users to make applications that leverage OpenAI's models.

After launching it, we started to think, "Could you now build Create inside of Create?"

So we tried:

It isn't Create - but it is functionally similar to Create.

There is an input that allows the user to type in a high-level app description. That request gets translated into code and then rendered in an iframe. This is pretty close to the app that we first launched 3 months ago!

Even getting close is exciting for the reason self-hosting is exciting:

We're a team trying to build an incredible product that users love. We want teams on Create to build incredible products that their users love.

In fact, we hope you use Create to build better products than Create. Just like old programming languages are used to make better programming languages.

Create isn't yet self-hosted, but we want it to be.

Bootstrapping a self-hosted tool

Self-hosting requires you to overcome the bootstrapping problem. In simple terms, this is a bit like solving a chicken-or-egg problem.

It's quite the journey to go from a language that is compiled by another language to a language that is compiling itself. Typically, it begins with creating a more limited compiler that is capable of compiling it's own source. Then from there, you can create a more advanced compiler from that compiler in the language that you're building on.

The core language of Create built apps is English, so to get to self-hosting, we'd need to first start by managing our source-code in English.

Once we've gotten an initial version of Create running on English as source code, we might then incrementally start adding additional features to the product running in English.

Large language challenges

The challenges of self-hosting a tool are amplified by the nature of large language models, or LLMs, which are a key part of the product we've been building.

Because LLMs have probabilistic outputs, their outputs become harder to reproduce. Less reproducibly makes testing harder.

Small changes to prompts can result in totally different outputs. Additionally, the models are constantly being improved. Prompts that were previously working well may no longer work as intended.

Choosing not to take advantage of the most advanced models often means having more limited capabilities or worse performance. This is obviously a non-starter.

So we're faced with the challenge of moving towards self-hosting with an underlying substrate that's constantly changing underneath us.

So what?

Overcoming the bootstrapping problem isn't easy to do and will inevitably require a lot of effort to get right.

Our mission is to give everyone the power of software. This includes non-technical people. And we want to give them the full power of software, not some neutered version of software.

Software has created a lot of value in the world and we believe with the right set of tools, anyone should be able to harness it to its full capability. By definition, this is only possibly if you're capable of self-hosting the tool.

We also believe this will lead to an incredible change in the world. By most estimates, there are less than 30 million software developers in the world. What would happen if tools like Create could increase that figure to 1B or more? Would software become more individual? Would it become more temporal? We're still figuring it out.

We've been tinkering with some features internally that have enabled our (non-technical) designer, Zaria, to build parts of Create with Create, and the results have been surprising.

She has built things in Create that are currently running in production that are higher quality than what I'd expect of a typical software engineer, and she was able to ship them in less time than expected.

That simply would not have been possible before. We're building towards a world where everyone is capable of being an engineer.

We're just getting started. We plan on adding more integrations, data storage, and authentication soon. Eventually we want to turn even more of the functionality of Create onto Create itself.

If we're successful, one day you might build a better version of Create on Create.