The preview is not the product
Watch a demo of any AI app builder — ours included — and you'll see the same arc: a prompt, a progress feed, and then an iframe with a working app in it. Applause. The iframe is real, the code is real, and the hard-sounding part — an AI wrote a full-stack application — genuinely happened.
But the iframe is a preview, and a preview makes almost no promises. It doesn't promise to be there tomorrow. It doesn't promise that the next iteration won't wipe its data. It doesn't promise anything to the second user, because there usually is no second user. Generation got easy; the demo is the easy 80%. The product is the other part — the one that starts the moment a stranger types a URL and trusts your app with a row of their data.
This post is the inventory of that gap. It's also the design stance the whole platform is built on, stated once, plainly:
The agent is allowed to be wrong. The platform is not.
Every mechanism below exists to make some failure of the agent — or of the infrastructure under it — survivable as a matter of system invariant, not of model behavior.
What "production" actually demands
Data that outlives the next deploy
The preview's database is a scratchpad; production's database is a promise. The moment real users write rows, "deploy" stops meaning replace everything and starts meaning change the code, apply the migrations, touch nothing else. On this platform that's structural: production has its own data timeline from the first release, deploys apply pending migrations to it, and overwriting prod data with dev's is a separate, explicit, snapshotted act. There is no code path where it happens as a side effect.
Rollback that includes the data
A release that breaks isn't fully undone by reverting code — the migration already ran. Every release here tags a pre-deploy checkpoint on the production timeline before it touches anything, so rollback can restore code and data to the same coherent moment, under explicit rules about what it may delete.
Verification that can't be sweet-talked
A preview only has to look right once. A product has to be right after every iteration — including iteration forty, made months later by an agent with no memory of iteration one. That's why "done" is decided by compilers, live contract probes, and the app's own tests, never by the model's self-assessment. The interesting property: the contract is the architect's declaration, so a feature the producer quietly skipped fails verification even though all the code it did write is fine.
Secrets nobody pasted
The preview can fake credentials; production can't. Every credential here — database URLs, service passwords, API keys — is generated at provisioning time, stored in Vault, and injected into the namespace as Kubernetes Secrets along one mandatory path. The agent composes against environment variables it never sees the values of. There is nothing to leak into a prompt, because the prompt never contained it.
An idle cost of zero
A platform that hosts every weekend idea only works if an idle idea costs nothing. Frozen containers and Postgres compute that scales to zero and wakes mid-connection make "keep it running, just in case" the default instead of a monthly bill. The inverse — an app whose users won't tolerate a cold start — is a deliberate, priced choice (keep-warm), not an accident of architecture.
Survival of its own construction
The most underrated production requirement: the factory itself crashes. Builds are long; pods get evicted; processes get OOM-killed mid-write. A reconciliation sweep treats "the build died" as a normal input — every interrupted run is detected and every piece of state it held is returned to a consistent, resumable picture. A platform that can't recover its own half-finished work would eventually strand a customer's project in a state no button can fix.
Why this is a platform problem, not a model problem
Each item above has the same shape: it must hold for every project, on every iteration, regardless of what the model emits. That's the definition of an invariant, and invariants don't live in prompts. They live in namespaces, branch topologies, append-only ledgers, verification gates, and reconciliation loops — the boxes in the anatomy post.
Better models keep arriving, and we swap them in the day they do — the engine treats models as configuration. What doesn't change with the model is the question the platform answers: what must stay true no matter what the agent does? The preview is what the agent made. The product is everything that stays true around it.
The rest of this blog walks those invariants one system at a time — the database built for agents, the deploy that moves no bytes, the undo button for data, the namespace model. And the gallery shows the output: one real app a day, with the prompt it came from and what it cost to build.