There's a reason most side projects stop improving the day they launch: every change after launch feels like it might break the thing that finally works. That fear is rational when edits happen in place. So here, nothing happens in place.
Every change is a version
Ask the build chat for a change — a small copy tweak or a whole new feature — and the platform produces a new version next to the old one. Both stay previewable. Both stay downloadable. The old version doesn't become an archive footnote; it stays a working product you can put back with a click. Once changing things is provably reversible, you change more things, and products that get changed more get better faster.
Verification applies to version 9, too
A common failure of iterative AI editing is regression: the fix for one thing quietly breaks another. Every version here runs the same verification chain as the first build — code review, security, links, accessibility, conformance — so a change that breaks something gets caught in the round that introduced it, not by your users. (More in How builds verify themselves.)
Your server gets a history as well
Deployments to your own host over SFTP are versioned on the host itself: the previous webroot is captured before each deploy, and every deployed version is kept and restorable. The one-click revert exists for the deploy that looked great in preview and wrong in production. Publishing to your free subdomain gets the same keep-everything treatment.
| Where | What's kept | Undo |
|---|---|---|
| In the builder | Every version, previewable and downloadable | Restore any version |
| Your subdomain | The published version, replaceable anytime | Republish an earlier version |
| Your own server | Pre-deploy capture + each deployed version | One-click revert on the host |