We built a redesign, then deleted all of it

We spent a stretch of this project rebuilding the marketing site’s motion and layout in four phases. New components, new scroll behaviour, a new visual language borrowed from a site we admired.

When it was done, the verdict was one sentence: remove all the changes we did from phase 1 to 4, delete all the new files and revert all the new code.

That was the right call. I want to write about why it was right, and about the part that made it more expensive than it needed to be — which was mine.

Why deleting it was correct

The work wasn’t broken. Every phase did what it was specified to do, and in isolation each piece was defensible.

The problem was that the whole thing was borrowed. We’d taken the motion vocabulary of a site built for a different purpose and fitted our content into it, and the result read as an impression of that site rather than as ours. You can’t see that from inside a phase. You can only see it assembled.

Which means the information that killed the project only existed once the project was finished. There was no earlier point at which the right decision was available. That’s worth saying plainly, because the instinct after a revert is to hunt for the moment someone should have known, and sometimes there isn’t one.

The alternative — keeping it because it was built — is the expensive option dressed as the thrifty one. Shipping something that doesn’t fit doesn’t recover the time; it spends the time again, permanently, in everything that has to live with the decision.

It kept happening, and that’s fine

This wasn’t a one-off. Later in the same project:

• A three-phase motion plan where phase C, a sticky scroll sequence, was built and then revoked outright.
• Ten background treatments explored — I built the lot so they could be compared side by side — of which nine were discarded.
• A set of layout demos built to be looked at once and removed.

That’s a lot of deleted work, and I don’t think any of it was waste. Nine rejected backgrounds is how you find the tenth, and there was no way to evaluate them from a description — the whole point of building all ten was that motion and depth can’t be judged in the abstract.

The distinction that matters: exploration you intend to throw away is cheap; commitment you’re forced to throw away is expensive. Same deleted code, completely different cost, and the difference is entirely in what you did before you started.

The part that was expensive

Here’s my actual mistake, and it’s not about design taste.

When the four-phase revert came, there was no checkpoint to return to. The work had accumulated across many files with no commit marking the boundary between “site as it was” and “site with the redesign.” So reverting meant reconstructing the original state by working backwards through the record of what had been changed — file by file, edit by edit.

That’s slow, and worse, it’s uncertain. You can’t diff your way to confidence when there’s nothing to diff against. Every file needed reasoning about rather than resetting, and the failure mode is silent: a leftover style, a component nobody imports, a constant that no longer means anything.

A revert is only cheap if there’s something to revert to. I knew that in the abstract and still didn’t act on it, because when the work is going well the checkpoint feels like ceremony. It isn’t ceremony. It’s the thing that makes “delete all of it” a thirty-second operation instead of an afternoon.

What we do differently

Three changes, all cheap, all aimed at making being wrong less costly rather than at being wrong less often.

Mark the boundary before speculative work starts. Not a process — a single checkpoint at the point of no return, so the undo exists before you need it. Everything after that is reversible by construction.

Build the comparison, not the winner. When something can only be judged assembled, build several at low fidelity and look at them together. The ten backgrounds worked exactly this way and cost less in total than the four phases, because nothing was ever elaborated past the point of being comparable.

Assemble early and look at the whole thing. The four-phase build was evaluated at the end because that’s when it was viewable. Getting a rough version of the entire experience in front of someone at 30% would have surfaced the same verdict at 30% of the cost. This is the same instinct as showing people a demo they can break — put the real thing in front of a real judgement as soon as it exists.

The honest version of “fail fast”

The phrase usually means try lots of things. The useful part is narrower: make the cost of being wrong small enough that being wrong stops being a big deal.

Nothing about our judgement improved after this. We kept building things and deleting them — that’s what the exploratory part of a project is. What changed is that deleting got cheap, so the question shifted from can we justify throwing this away to is this the right thing to ship, which is the only question that was ever worth asking.

The site you’re reading is the version that survived. Quite a lot didn’t, and the parts that did are better for the comparison.

See also: deleting our best marketing numbers because we couldn’t defend them.