I Tested 9 AI Build Tools. Only Some Let You Keep What You Make.
On July 28 we ran Build to Keep, a free live workshop about a question almost nobody asks before they start building: if the tool you used disappeared tomorrow, would you still have your work?
The whole thing is above. Below is what we found, including the scorecard from testing nine AI build tools against the same two prompts.
The thesis, stated plainly about two minutes in:
The stuff that you build with AI should be yours tomorrow. Whatever you choose to build, it needs to be yours within your control. Not in a vague sort of feel-good way, but the code should be on your machine, on the repository attached to your account, so that you can walk away from any tool that you use and the stuff that you made stays with you.
Everybody has already lost something they made
We opened by asking the audience whether they had ever lost something they made online. The answers came fast. Vine. Google Reader. Mint. MySpace pages. A show that vanished off Netflix. A game pulled from a storefront.
What’s funny is this is such a universal problem. Everyone’s inundated with these subscription services and then those services take the thing that they liked away and then you realize, oh, I guess I never own this in the first place.
That is the pattern. You were renting access the entire time, and the bill came due the day the service shut down.
Here is the version that lands hardest. Think about buying a song on iTunes in 2005 versus ripping the same song off a CD you owned. The purchased file had DRM and was tied to one ecosystem. The ripped file was just a file. Twenty years later, whichever one you ripped still plays on anything.
Most AI build tools want to be your landlord
That framing comes straight from the workshop, and it holds up:
A lot of these tools want to be your landlord. They hold your code. They hold your data. They hold all these things as you’re trying to build. And if you leave, you got to start from scratch.
Some platforms gate code export behind a paid plan. Others hand you the frontend while the backend stays welded to their SDK and their managed database. You can be shipping fast and still be renting every part of what you shipped.
To be clear, renting is not automatically bad. You rent on purpose all the time, and nobody should be running their own mail server. The rule we landed on is simpler than “own everything”:
The more you rent, the more portable it needs to be. Own something outright and portability barely matters. Rent it, and portability is the only insurance you have.
Worth hearing this from someone whose company benefits from the opposite. We asked Matt Biilmann, CEO of Netlify, about lock-in in an AMA:
It’s better for them if they box everything into one vertical stack, and better for the rest of us if they don’t.
He followed it with the cleanest line of the whole workshop:
The web is the only open platform we have that isn’t owned by anyone. So I think that’s worth building on.
The experiment: nine tools, two prompts
We gave nine AI build tools the exact same two prompts. First, build a simple personal page. Second, do it in Astro, which for most of these tools means stepping outside the React stack they were designed around.
That second prompt is where things fell apart. It is a completely normal request, and it separated the tools that hand you a project from the tools that hand you a hostage.
Then we scored each one on whether you can actually walk away with what it made. The rubric was six questions: can you own the code, can you move it to other tools, do you get a custom domain without paying, is there a forced vendor badge, is it actually live, and did you get to pick the framework.
| Tool | Score |
|---|---|
| Cursor | 95 |
| Netlify Agent Runners | 93 |
| Google Antigravity | 93 |
| Claude Code | 87 |
| bolt.new | 60 |
| Replit | 50 |
| v0 | 42 |
| Lovable | 28 |
| Base44 | 15 |
A few things worth sitting with.
The tools at the bottom are the easiest ones to start with. That is not a coincidence, and it is the real lesson of the whole exercise. Easy to start and easy to leave are two completely different properties, and the marketing for these products only ever advertises the first one.
Open source alone does not save you. bolt open-sourced their core, and the hosted product still stamps a badge on your site and pins your deploy to their domain. “Open source” is not a synonym for “yours.”
Lovable told us Astro does not exist. Asked for Astro 7, it said no such thing existed and that only React was supported. At least it was honest about the second part.
Base44 hit every warning sign at once. Asked for Astro, it explained that its apps run exclusively on React and that the hosting, database, and integrations all run on that stack, so it could not port. Trying to export the project as a zip returned an upgrade prompt. There is a forced badge, and it is owned by Wix.
One thing worth repeating from the stream, because it matters:
This is not intended to make you feel bad if you like using some of the other ones that I was critiquing. I’m not here to dog on it. I’m just here to show you which platforms you’re most likely to be stuck in if you wanted to move in the future.
The surprise tenth tool
After the nine, we tried OpenCode with the same brief. Every web builder had handed back a React and Vite application for what was, in the end, a simple page about a person.
OpenCode returned a single index.html.
Every other tool tried to overengineer this crazy complex React app for something so simple. And the big pickle, I’m not kidding, it’s called big pickle. This model was the only one to say, this isn’t that complicated, I’m just going to make an index.html file. And it was perfect.
Yes, the model that won is named Big Pickle.
There is an honest tradeoff: it does not help you deploy. But it was the only one that read the actual request instead of reaching for a framework.
Then we moved the thing across three tools, live
The demo was the point of the whole workshop. Start a build in one tool, export it, restyle it in another, preview it, then put it live on hosting you control and connect it to your own repository.
Nothing about that flow is exotic. It just requires that every step hands the work forward instead of holding onto it. That is the entire test.
The lock-in nobody warns you about
The lock-in that actually hurts is not the editor you build in. It hides in the boring plumbing.
- Your database. A managed database wired to one platform’s SDK is the hardest thing to move later.
- Your domain registrar. If the platform registered it for you, check whose name is on it.
- Your keys. This is the one people miss.
Some of these tools go, hey, look how convenient this is. Just plop the key in there and then don’t worry about it. And that’s not necessarily the right approach. You want to save them in something like a password manager. You don’t want to be relying on these platforms to do that.
If a service generated a key, stored it, and never showed it to you again, you do not really have that key. You are borrowing it. Keep the canonical copy of every API key and token somewhere you own.
Own the workflow, not just the code
Jon Tuite from OpenRouter joined for the second half and extended the idea into the AI layer itself. If you can swap the model behind your workflow by changing one string, then no single AI company owns how you work either.
He covered agent harnesses, why AI bills explode the way they do, why open weight models are often cheaper, and set up a harness live so people could see what it actually takes.
He also delivered the spiciest line of the stream, on free tools generally:
Just know that Discord, it’s free for a reason. You get what you pay for. Just like Gmail is not technically free. You are the product.
The good news: lock-in is getting weaker
Here is the hopeful part. The cost of moving between stacks is collapsing.
Someone rewrote Bun from Zig to Rust for roughly $150,000 in tokens. Airbnb moved 3,500 test files off Enzyme in about six weeks, against an internal estimate of eighteen months by hand.
Six weeks against eighteen months changes what lock-in even means. Migrations that used to be permanent decisions are becoming ordinary work.
That only helps you if you can get at your code in the first place. Which brings the whole thing back around.
What to actually do about it
Practical version, in order:
- Get the files on your machine. If you cannot download the project, you do not have it. Test this early, not on the day you want to leave.
- Put it in your own repository. Your GitHub account, not the platform’s.
- Own your domain. Register it yourself, in your name.
- Keep your own copy of every key. Password manager, not a platform dashboard.
- Prefer boring, portable formats. Plain files travel. Proprietary project formats do not.
- Pick hosting you can leave. Static output on a host you control moves in minutes.
None of this slows you down. You can still build fast with AI. The point is not to build slowly, it is to make sure the thing you built keeps existing after your relationship with the tool ends.
Built something with AI and not sure what is under the hood? An ERA audit reads the code an AI wrote and reports back on security, architecture, and test coverage, findings included.
Get an ERA auditWatch the whole thing
The full workshop is embedded at the top of this post. Some chapters worth jumping to:
- The nine-tool test and the scorecard
- The live migration across three tools
- Jon’s segment on agent harnesses and swapping models
- Building presentations in HTML instead of PowerPoint
Thank you to Netlify, OpenRouter, and Astro for sponsoring, and to everyone who showed up live and filled the chat.
If you want the deeper background on why this matters for a business rather than a side project, we wrote about vendor lock-in and how to avoid it, and there is a website build checklist for shipping a site you actually own.
Go build something you get to keep.
