Builders and runners: how to read the AI software market

Every week there is a new product that promises you do not need engineers anymore. They are not all the same product, and the difference matters more than the feature lists suggest.

There are two jobs here, and most products only do one of them.

A builder turns a description into software. You type what you want, it writes the thing. Lovable, Bolt, v0, Base44, and Replit’s agent all live here, as do the older no-code tools like Bubble and Glide where the “writing” is done by dragging.

A runner takes software that already exists and keeps it available. Vercel, Railway, Render, Fly, and the big clouds live here. They do not care where the code came from. They care that it starts.

Most of the market has quietly become both, which is why the categories blur. But the seam between them is exactly where non-engineers get stuck, so it is worth pulling apart.

The orphan case

Here is the situation almost nobody’s product is shaped for.

You did not use a builder. You used the assistant you already had open. You asked Claude or ChatGPT for a script that reconciles two CSV exports, or a tool that cleans up a CRM import before anyone loads it. It wrote it. It works.

You now have a folder on your laptop. Not an account on a platform, not a project in a workspace, just files.

Builders cannot help you, because you did not build it there and most of them have no meaningful “import my existing folder” path. Runners can help you in principle, but they were designed for engineers and they ask which repository to connect and what the build command is before they will do anything.

That is the orphan case, and it is common precisely because general assistants are the most-used AI tools by a wide margin. The most popular way to get software written produces output that the ecosystem has the least idea what to do with.

What you actually own

If you are going to put your team’s workflow inside one of these things, the question worth asking early is what you would be left holding if you left.

The builders that generate real code tend to be fine here. Lovable syncs to a GitHub repository you control. Replit lets you download the project or push it to GitHub. v0 pushes to your repo. Claude’s artifacts and ChatGPT’s code output are just code; you can copy it out and it does not stop working.

The visual no-code platforms are a different story. Bubble, Glide, and Softr do not give you source code to take anywhere, because in a real sense there is no source code to take. What you built is a configuration of their runtime. Leaving means rebuilding, and people do discover this at the worst possible moment, usually when the app got popular enough to matter.

Neither model is wrong. A visual platform that owns the runtime can do things a pile of exported files cannot, and plenty of teams are happy inside one for years. But it is a decision, and it is usually made by accident.

There is a middle case worth watching too. Retool sits in the internal-tools slot and does offer Git sync and a self-hosted option, which is unusual for its category. Airtable’s interfaces are portable in the sense that your data can leave, while the interface itself cannot.

The thing that gets skipped

Read the marketing for every product in both categories and you will notice what is almost never on the page.

Speed is on the page. Every one of them promises minutes. Accessibility is on the page too, in some phrasing of “no code required.”

What is not on the page: what you are left with the month you stop paying, and who is allowed to open the thing you made.

That last one is the quiet problem for internal tools specifically. A share link that works for anyone who has it is fine for a prototype and wrong for a tool that reads compensation data. Several of the most accessible options in this market, including the artifact-style outputs from the big assistants, use exactly that model. Anyone with the link is in.

For a lot of what knowledge workers build, that is the difference between a tool they can send to the rest of the team and one that stays on their own machine.

A caution about building on someone’s feature

One more thing that only shows up over a long enough timeline.

Features get removed. A workspace, a canvas, an artifact type, a hosting tier: all of these are product decisions at a company optimizing for something other than your workflow. When a feature you depend on gets folded back into the main product or retired, you find out when someone opens the link on a Monday and it is not there, and the migration path is whatever you can improvise that morning.

This is not an argument against using any of them. It is an argument for knowing which category you are in. If your tool is a pile of code you own, a platform change is an inconvenience. If your tool only exists inside someone’s runtime, a platform change can be the end of it.

Where Sploot sits

For honesty’s sake: Sploot is a runner, not a builder. It will not write your app. It assumes something else already did, and it does not care what.

The bet is that the orphan case is the big one. Not “help me build software,” which several products now do well, but “I already have working software and no idea where to put it.” So the input is a folder or a zip rather than a repository connection, and the sign-in is there before you ask for it. The code stays yours in a form you could take elsewhere.

It is in private beta and there is nothing to log into yet. But the category read is the useful part regardless of what you end up using. Work out whether you need something to write your software or run it, and check what you would be holding if you walked away.