Why does editing something that already works feel risky? Because most tools let you edit in place — you save over the old version, and if the change breaks something, there's no version to go back to. That fear is entirely rational when there's no undo. So here, there isn't an "in place." Every edit produces something new next to what was already there.
What actually happens when I ask for a change?
You tell the build chat what you want — a copy tweak, a new section, a whole feature — and the platform produces a new version alongside the old one. Not instead of it. Both stay previewable, both stay downloadable, and the old one isn't demoted to some archive you'd have to dig for. It's a working product, one click away from being the live one again. Once reversing a change is that cheap, you stop treating every edit like a bet.
Doesn't re-running full verification on every version slow things down?
It's the opposite problem verification solves. The usual failure mode with iterative AI editing isn't the change itself — it's the thing that change quietly breaks somewhere else. Fix the pricing page, and the nav link to it silently 404s. So version 9 gets the exact same chain version 1 got: code review, security, link checks, accessibility, conformance. If a change breaks something, it gets caught in the round that introduced it. Not three weeks later when a user emails you about a broken button. (Full detail in How builds verify themselves.)
What happens when I deploy to my own server?
Deploys over SFTP to your own host get the same treatment, just one layer down. Before anything gets written, the platform captures your current webroot. Every version you've deployed after that stays on the host and stays restorable. So if a deploy looks perfect in preview and then something on your production stack — a cache header, a weird CDN rule, whatever — makes it look wrong once it's live, you revert with one click instead of re-deploying an old export and hoping you grabbed the right one.
What about the free subdomain?
Same idea, lighter weight: publishing there keeps every published version too, and republishing an earlier one is just as easy as publishing a new one.
| 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 |
Isn't this all just a fancy backup system?
No — a backup system protects you from disaster. This is meant to change your day-to-day behavior. When the cost of a wrong guess drops to a click, "let's just try it" stops being a risky suggestion and becomes the default answer to almost every idea.
