About
A builder that hands back its work.
Almost everything in this category will write you a website and keep it. The whole of Blank follows from refusing that — and from three decisions that make refusing it possible.
The problem with a preview
Generated software demos brilliantly and ends in the same place: something that lives inside somebody else’s product. You can publish it. You cannot open it, cannot fix a detail the model got wrong, cannot point a colleague at the code, and cannot leave with it. The moment your needs exceed what the tool anticipated, you are stuck — and you have no way to find out how close to that line you are until you cross it.
That is not a limitation of the models. It is a business decision about where the work lives, and it is the one decision Blank makes differently.
Three decisions, and what each one cost
1. The output is a real project, so there is no proprietary format
React and TypeScript in a conventional folder structure. No component descriptors, no JSON scene graph, no runtime only we can interpret.
What it cost:a huge amount of leverage. A proprietary format would let us change the renderer, migrate every customer’s site at once, and guarantee that nothing anybody built can break. Real files mean the model has to write code that is actually correct, we cannot fix a site retroactively, and every generated project is ours to get right the first time.
2. The build stops for a person before it touches data
The moment a build needs to store something, it halts and submits the routes and the tables for approval. There is no tool in the engine that can approve a schema — only a person can.
What it cost:the demo. “Describe a site and watch it appear” is a better thirty-second video than “describe a site, review a schema, then watch it appear”. We took the worse video because a frontend built against a schema nobody agreed to has to be rewritten the moment the real one arrives, and that rewrite is where generated applications go to die.
3. Generated code never runs on our origin
Every site gets its own hostname, and this application is unreachable there. A generated page cannot read your session because it is not on the same origin as your session.
What it cost: real engineering, and one feature we had to give up first. The original design ran generated sites in an opaque origin, which was simpler and denied those pages localStorage — so a generated app could not use Supabase auth at all. Fixing that properly meant per-site hostnames and enforcing the boundary in both directions. The security page sets out how.
Who it is for
People who can read the code, or who work with somebody who can. If you never intend to open a file, a tool that keeps the files is genuinely simpler and you should use one. If you have ever been stuck inside a builder — waiting on a feature request to change something you could have fixed in a minute — this is built for that.
How it is paid for
Subscriptions, metered on what the models actually cost rather than on tokens. No free tier subsidised by selling anything: your projects, your prompts and your conversations are not a product. The admin area that can read a conversation requires a stated reason and writes an audit row beforethe read, so “who has looked at my messages” is a query rather than a promise.
Every file, readable
React and TypeScript in a real folder structure.
Your database
Your own Supabase, with Row Level Security.
Your domain
A subdomain, or one you already own.
Your repository
The whole project, pushed to GitHub.
Try it on something real.
The free plan is enough to finish one complete small site, and everything it writes is yours whether you stay or not.