Undo Is Not a Button: Designing Software That Can Recover From Mistakes

A founder can spend weeks discussing the happy path of a workflow and only minutes discussing what happens when someone changes their mind.

That imbalance is understandable. Product demos are built around progress. A customer creates a record, a staff member advances a job, a file is approved, a message is sent. Every screen seems to move forward.

Real work is messier. People click the wrong control. They notice a typo after saving. They replace the wrong file. They mark something complete too early. Sometimes the action is still local to the software and can be reversed cleanly. Sometimes the action has already changed another system, another person’s expectation, or the physical world.

“Undo” is therefore not a single feature. It is a family of product decisions.

A useful product does not promise that everything can be rolled back. It gives people a correction model that matches the action they took.

A fictional print shop with four different mistakes

Consider Alder Street Printworks, a fictional small print shop. It is not a Racoben client, case study, or measured result. The business uses an internal workflow app to manage customer jobs from approved proof to production.

A job record contains a due date, a current proof file, a production status, and notes for staff. The team wants the interface to feel forgiving. During an early review, someone writes a seemingly simple requirement: “Users should be able to undo mistakes.”

Then four ordinary mistakes happen.

A staff member changes a due date from Thursday to Tuesday and immediately notices the typo.

Another person moves a job from “proof approved” to “ready to print,” then realizes the customer’s final approval has not actually arrived.

A designer uploads a revised proof, replacing the previous file, and later discovers that the old version contained a detail the customer wants restored.

Finally, an operator releases a job to a physical printer. Sheets begin coming off the machine before anyone notices that the wrong paper stock is loaded.

All four events feel like “mistakes.” They do not deserve the same correction mechanism.

The due date might need a simple undo. The workflow status might need an explicit reversal that staff can see. The proof file might need version history. The print run cannot be made historically false; the best the system can do is record what happened, stop what remains stoppable, and create a correction path.

That distinction is the product problem.

The first kind of correction: immediate undo

The simplest correction is close to what people expect from a text editor. A person performs an action, realizes it was wrong, and reverses it before much else has happened.

Apple’s Human Interface Guidelines on undo and redo describe undo as a way to reverse recent actions and emphasize that people need to understand what an undo will affect. The guidance also recommends making the result visible, because an undo that changes something offscreen can otherwise be confusing.

For Alder Street Printworks, changing a due date is a good candidate for this model. The user edits “Thursday” to “Tuesday.” The app can briefly offer “Undo due-date change.” If the person chooses it, the record returns to the earlier value.

The important product detail is not the presence of an arrow icon. It is the scope.

If the user changed only the due date, undo should not also roll back an unrelated note someone else added a moment later. If the app simply restores an entire old copy of the job, the correction mechanism may erase valid later work.

This is why “undo” has to be defined at the level of the action.

An engineer can implement a mechanism that reverses a change. The founder or product owner still has to answer a more basic question: what counts as one change from the user’s point of view?

That answer may be a single field edit, a drag-and-drop move, or a batch operation. It should match the way people understand the task.

The second kind: history instead of a rewind button

Some changes are too important to reduce to one step backward.

Alder Street’s proof files are a good example. The designer uploads a revised PDF after a customer requests a change. Two hours later, the team discovers that an earlier version contained the correct disclaimer.

A one-step undo could be risky because other edits may have happened since the replacement. What the team needs is not “go back one action.” It needs a history of meaningful versions.

Google Docs provides a familiar example of this different model. Its version-history documentation explains that people can view earlier versions, restore an earlier version, or make a copy of one. That is a different product capability from ordinary undo: instead of assuming the most recent action is the one to reverse, the user chooses a historical state.

For Alder Street, a proof-history feature might preserve each approved or uploaded proof as a labeled version. The current proof remains the current one until someone explicitly restores another version. The product can show who made the change and when without pretending that history never happened.

This design is valuable when the important question is not “what was my last click?” but “what did this record look like at a meaningful point in time?”

But version history has a resisting case: keeping history has costs.

At the infrastructure level, Amazon S3’s versioning documentation illustrates the basic tradeoff. S3 can retain multiple versions of an object so an overwritten or deleted object can be restored, but each version is stored as an entire object and normal storage charges apply. That is an infrastructure example, not a recommendation that every product should use S3 versioning.

The founder-level lesson is broader. Retaining every old state is not free. It can increase storage, create more data to govern, and make the interface harder to explain. Some products need years of detailed history. Others need only a few meaningful versions. Some need to remove old information deliberately.

“Keep everything forever” is not automatically safer than “keep nothing.”

The product decision is to preserve enough history to support the corrections people actually need.

The third kind: a compensating action

Sometimes the right correction should not erase the original action at all.

Git offers a useful technical analogy. The git revert documentation explains that reverting a commit creates a new commit that reverses the effect of an earlier one. The earlier commit remains part of the history.

That pattern maps well to business workflows where history matters.

Suppose an Alder Street manager marks a job “ready to print.” A few minutes later, the customer asks for another proof change. If the product simply rewrites history to make it appear that the ready-to-print state never happened, staff may lose useful context about why the job left the queue or why a production step was interrupted.

A compensating action can be clearer.

The system records that the job was marked ready, then records that it was returned to proof review. The current state is correct, and the history remains intelligible.

This is not the same as an audit log for compliance, and founders should avoid assuming that a history list automatically satisfies any legal or regulatory requirement. The product value is simpler: a later reader can understand the sequence of decisions.

Compensating actions are especially useful when the original action may already have influenced people or systems. A cancellation does not make a prior confirmation disappear. A reopened ticket does not mean it was never closed. A corrected status can preserve the fact that the earlier status existed.

That makes the interface slightly less magical, but often more honest.

The fourth kind: an action that cannot really be undone

The hardest category begins when software changes the outside world.

In Alder Street’s fictional workflow, releasing a job to the physical printer is different from changing a database field. Once sheets have been printed, no software operation can make the paper unprint.

This is where product teams can misuse the word “undo.”

A database can roll back some changes that are still inside a transaction. PostgreSQL’s ROLLBACK documentation describes rollback as aborting the current transaction and discarding its updates. Its savepoint documentation also allows part of an in-progress transaction to be rolled back to a savepoint.

Those mechanisms are powerful, but their scope matters. Rolling back a database transaction does not pull printed sheets back through a press. It does not unsend an email or make another person forget a notification they already saw.

Once an effect has escaped the software boundary, the product needs a different response.

For Alder Street, the release-to-print action might deserve a more deliberate interaction than an ordinary status change. The product could show what job is about to be released and make the user explicitly confirm the production action. If the printer accepts a cancellation command and has not started yet, the system may be able to stop the job. If production has begun, the correction becomes operational: stop the remaining run, record waste, correct the job, and release a new version.

That is not undo. It is recovery.

Apple’s alert guidance makes a related interface distinction. Apple advises against interrupting people with alerts for common actions that can be undone, while treating uncommon destructive actions that cannot be undone as better candidates for confirmation.

The broader product lesson is useful beyond Apple platforms: confirmation is most valuable when it protects a meaningful boundary, not when it becomes a reflex attached to every button.

Too many confirmations can be as bad as too little recovery

If a founder responds to mistakes by adding confirmation dialogs everywhere, the product can become exhausting.

“Are you sure?” appears before a status change. Then before a file upload. Then before renaming a job. Eventually the warnings become background noise.

A better question is whether the product can make the action safely reversible.

The better response depends on the consequence. A due-date change probably does not need a confirmation dialog; the user should be able to make the edit and undo it. Replacing a proof is better served by version history than by repeated warnings, because the earlier file may need to be recovered later.

A workflow-state correction is different again: a visible compensating action can preserve what happened while restoring the current state. Releasing the physical print job crosses a harder boundary, because the external consequence is more difficult to reverse and may justify confirmation before the action proceeds.

The product should spend friction where irreversibility begins.

That principle has a practical side effect: it helps founders separate interface polish from system design. A confirmation dialog is easy to add, but it does not create recoverability. An undo button can look reassuring, but it does not tell you whether the underlying action can actually be reversed without damaging other state.

Correction semantics change the data model

This is where a seemingly small product decision reaches into engineering. The implementation needs are different for each correction model: immediate undo requires enough information to reverse the specific action safely, while version history requires earlier meaningful states plus a defined way to restore them.

Compensating actions need the system to record state transitions instead of simply overwriting the past. Irreversible actions shift the engineering problem toward prevention and a recovery path for what happens after the fact.

These are not implementation details a founder needs to design alone. But the founder does need to define the intended behavior before engineering can prove it.

For Alder Street, “restore the previous proof” should answer several product questions.

Does restoring an old proof create a new current version, or does it erase newer versions? Does the restored file become immediately printable? Does the team need to reapprove it? What happens to notes attached to later versions?

The same ambiguity appears in ordinary editing.

If someone changes a customer name and then uses undo, should the app restore only the name or the entire record? If another staff member changed the delivery address in the meantime, the correction should not silently erase that separate update.

Correction semantics are therefore partly about concurrency: other valid work may happen between the mistake and the attempt to correct it.

The more collaborative the product becomes, the less safe it is to think of the entire record as one giant undoable object.

A useful founder test: what must remain true after correction?

The founder does not need to choose an architecture before talking to an engineer.

A more useful starting point is to describe the invariant after correction.

For Alder Street:

• After undoing a due-date edit, the earlier due date should return without removing unrelated later edits.
• After restoring a proof, the chosen proof should become current while the history remains understandable.
• After reversing a workflow status, staff should see the corrected current state and still understand that the earlier transition happened.
• After an irreversible print release, the system should help the team stop what remains stoppable and record the corrective next step rather than pretending nothing occurred.

These statements are more useful than “support undo.”

They describe what a person should be able to rely on after something goes wrong.

From there, an engineer can choose implementation mechanisms and test whether the behavior matches the product decision.

Not every product needs a permanent edit history

There is one more resisting case worth taking seriously.

The instinct to preserve history can become excessive.

An internal tool may not need every intermediate typo. A customer-facing product may not benefit from exposing years of trivial field changes. A company may decide that some information should age out rather than persist indefinitely.

Technical systems make preservation easy enough that teams can mistake it for the default.

But history is still product surface area. It has to be stored, explained, searched, restored, and sometimes removed. The more history exists, the more important it becomes to define which history matters.

Alder Street might decide to preserve uploaded proof versions and production-state changes while treating ordinary spelling corrections as current-state edits. That is a coherent boundary because it follows the business consequence, not the technical possibility.

The best correction model is therefore not the one that remembers the most. It is the one that gives people enough control to recover from meaningful mistakes without turning every keystroke into permanent product history.

The feature request behind “add undo”

By the time Alder Street finishes this discussion, “undo” is no longer a single feature request. A due-date edit can be cheaply reversible; a proof replacement can rely on version history; a workflow correction can preserve the original event while adding a corrective action; and an irreversible production step needs careful prevention plus a recovery path. Taken together, those are the distinct correction models hiding behind the word undo.

Founders do not need to predict every future mistake, but they do need to identify where a mistake changes only software state and where it creates a consequence outside the software. That boundary determines what kind of correction is credible.

A forgiving product does not promise that nothing is permanent. It makes the consequences understandable and gives people the right way to recover when recovery is possible.

For teams working through questions like these, Racoben Academy collects practical guidance on product scoping, technical decisions, and first-release evidence.

Sources

• Apple, Undo and redo
• Apple, Alerts
• Google Docs Editors Help, Find what's changed in a file
• Git, git-revert documentation
• PostgreSQL, ROLLBACK
• PostgreSQL, ROLLBACK TO SAVEPOINT
• Amazon S3, How S3 Versioning works