Why “move fast and break things” breaks design

A photo of a person holding a phone with the screen facing the camera. The screen reads “Something went wrong” and has a “Retry” button. The photo is cropped so the emphasis is on the phone, not the person.

I’ve watched teams ship broken flows at impressive speed. The velocity was real. So was the cleanup.

“Move fast and break things” made sense for shipping software experiments. It was never meant to be a design philosophy.

The two things it breaks most reliably: trust and foundations.

When you move fast in design, you’re not just skipping polish. You’re skipping the questions that catch problems before they become expensive. You’re skipping the edge cases that turn into support tickets. You’re skipping the accessibility review that someone will eventually need. And you’re skipping the documentation that lets anyone else understand what you built and why. 

But the trust piece is the one that doesn’t show up in a backlog.

Users don’t file bug reports when a flow confuses them. They just leave. Or they complete the task but with less confidence than they had before. They start to wonder if they did it right. They hesitate before clicking. They come back less often, or they call support, or they just quietly decide the product isn’t for someone like them.

That erosion is invisible until it isn’t. By the time it shows up in retention numbers or NPS scores, you’ve already lost months of trust you can’t easily earn back.

And here’s the part that stings: users don’t distinguish between “we moved fast” and “we don’t care.” To them, a confusing form is a confusing form. A broken state is a broken state. The internal reasoning is irrelevant. What they experience is what they remember.

The thing about broken foundations is that they don’t announce themselves. They just make everything harder later. You feel it in the redesign that keeps getting scoped down. You feel it in the design debt conversations that never go anywhere. You feel it in the new feature that somehow breaks 3 existing ones.

Speed in design is valuable. I’m not arguing for slow. But there’s a difference between moving fast with intent and moving fast to avoid the hard questions.

The question I try to ask instead: “What’s the minimum we need to understand before we build this?”

That’s not slower. That’s cheaper.