Did "Move Fast and Break Things" Age Badly?

What If Breaking Things Is No Longer Cheap?

For many years, the phrase "move fast and break things" represented a key aspect of startup culture: speed was important, experimentation was beneficial, and making mistakes was frequently preferable to going too slowly.

During Facebook's early years of expansion, the phrase became closely linked to the company and eventually came to represent a Silicon Valley way of thinking: create fast, try new things, learn from mistakes, and don't let caution stifle creativity.

And that made sense for a time.

You fixed anything that broke. If an experiment didn't work out, you learned from it. It could seem more expensive to move slowly than to make a mistake.

Today's software, however, looks much different.

More quickly than ever, startups can produce and deliver products. While digital products are increasingly linked to payments, personal data, corporate operations, and other aspects of daily life, AI-assisted coding is speeding up development.

Perhaps the question of whether startups should move quickly is no longer the most relevant one.

Do we still need to break things to do it?

Why "Move Fast and Break Things" Worked

Being careless wasn't actually the initial idea. It was all about trying new things.

The ideology emphasizes speed and experimentation over a careful and deliberate approach, as explained by MasterClass (2022). When occasional errors enable a business to innovate more quickly, they become an acceptable expense.

This way of thinking became particularly prevalent in software for a reason. After they are released, digital products can frequently be altered. In a comparatively short amount of time, a team can test a feature, observe what happens, resolve an issue, and release a new version.

That freedom is still important.

Startups that move quickly can test hypotheses earlier, react to customers more quickly, and avoid spending months creating something that no one really wants.

The problem begins when moving fast and breaking things become inseparable.

Breaking Things Is More Expensive Now

What exactly are we damaging?

According to Nevins, the expression made more sense when businesses were developing comparatively lightweight digital products in simpler systems, where many failures were inexpensive and reversible.

These days, a failure may not just indicate that a feature isn't functioning.

It can mean a payment is unsuccessful. User information vanishes. An account can no longer be accessed. A transaction takes place twice. A company that relies on a service cannot use it.

And sometimes, it's simply trust that fractures.

That changes the calculation. It's easy to fix a broken button. It could be far more difficult to win back a customer who has lost faith in the product.

The idea that "we'll fix it later" becomes increasingly costly as software gets more integrated into people's daily lives and businesses.

AI Made "Move Fast" Even Faster

Another reason this discussion seems particularly relevant right now is that software is being produced more quickly.

Small teams can now prototype concepts, write code, and conduct experiments far more quickly thanks to AI-assisted development.

That is a huge opportunity for startups.

However, more code, releases, assumptions, and potentially more problems come with faster production.

This does not imply that code produced by AI is inherently untrustworthy. It means that understanding what we are actually shipping becomes increasingly crucial as we produce more quickly.

The capacity to create software has increased. The repercussions of shipping a defective product have not disappeared with it.

Maybe "Move Fast" Was Never the Problem

There is also a danger in taking the criticism too far.

Moving slowly is not automatically responsible.

Even after months of striving to develop the ideal product, a startup may find that no one wants it. Experimentation is still important, and teams learn things from failure that they cannot learn from planning.

Lutkenhaus and Taylor (2025) draw a crucial distinction: better innovation, not less innovation, is the solution.

Software teams do not have to choose between:

Accept malfunctioning software and move quickly.

or:

Test everything indefinitely and never ship.

There is another option:

Move quickly, but develop a process that identifies issues before your users do.

Quality Is Not the Enemy of Speed

Testing can easily look like something that slows a team down.

Build the feature. Test it. Identify an issue. Send it back. Fix it. Test again.

Why not just ship?

Because skipping testing does not always eliminate that work. It often moves it somewhere else.

It might only take a short time for a developer to address a bug discovered before release. A customer discovering the same bug may result in support requests, investigation, reproduction, another deployment, additional testing, and potentially a loss of trust.

The team still pays for quality. It simply pays later and under greater pressure.

For this reason, quality shouldn't be considered an extra luxury that becomes necessary only when a startup gets "big enough." An effective quality process allows a team to keep moving without constantly going back to repair what has already been shipped.

From "Fail Fast" to "Learn Fast"

"Fail fast" should be replaced with "learn fast and reflect often," according to Lutkenhaus and Taylor (2025).

Software is especially well suited to that distinction.

The valuable part of failure was never breaking something. It was what the team learned from it.

Modern startups, then, may not need less experimentation. They need faster feedback.

Build fast. Test assumptions. Identify weaknesses. Learn, fix, and ship.

The speed remains.

The unnecessary damage does not have to.

Move Fast. Just Stop Breaking Things.

"Move fast and break things" pushed businesses to try new things rather than becoming stuck on perfection, which helped define a period of startup culture.

That lesson is still relevant today.

But its surroundings have evolved.

More significant aspects of our lives are impacted by software, and AI is enabling the production of that software more quickly than ever. The solution is not to become afraid of speed. It is to become better at managing it.

That is where QA fits.

At GetQA, we do not see quality as the department standing at the end of development saying "slow down." QA should help teams find problems while they are still cheap to solve, challenge assumptions before users have to, and give developers enough confidence to keep shipping.

Because moving fast is still an advantage.

Breaking things does not have to be.