Undo is the feature that makes people brave

The most common sentence we hear from a new founder is not a request. It is "can I try something?"

They are asking for permission, because everywhere else they have used software, trying something risked breaking something. And they are right to ask, because in most tools an experiment is a thing you then have to undo by hand, from memory, hoping you remember what it looked like before.

How it works here

Before any change runs, the state of your app is bookmarked. After it runs, the result becomes its own point in history. Undo is a return to the bookmark.

That distinction matters more than it sounds. Nothing has to reason about what changed, or reverse it step by step, or get it nearly right. The old state is still there, complete, and going back is going back to it.

Why exactness is the whole point

An undo that mostly works is worse than none, because you stop trusting it and start being careful. Careful founders ask for less, and the things they do not ask for are usually the interesting ones.

What it does not cover, honestly

• It does not unwind something your app already sent, or a payment a customer already made.
• It does not refund the change. The work happened; you are undoing its result.
• It is not a backup of things outside your project.

The change we noticed

Once people work out that undo is exact, the way they ask changes. They stop hedging. They say "try it with the photographs much bigger" instead of asking whether that would be a big change. They ask for the odd idea.

Most of the best pages we have seen on this platform came from somebody who felt able to try something and put it back. That is not a coincidence, and it is the argument for spending engineering effort on an undo that is exact rather than one that is approximately right.