Why 'Move Fast and Break Things' Quietly Still Guides Most Startups

If you’ve spent any time in a startup environment in the past decade, you’ve probably heard some variation of this: “If you’re not breaking things, you’re not moving fast enough.” It’s usually delivered with the confidence of someone quoting ancient startup scripture, accompanied by knowing nods and a implicit “this is just how we do things” energy. Here’s the thing: while the internet has collectively decided that “Move Fast and Break Things” is dead—killed by regulators, ethics, environmental concerns, and a general growing up of the tech industry—it’s actually thriving in practice. The motto didn’t die. It just learned to be more subtle about it.

The Ghost in the Machine

The phrase originated at Facebook as an explicit cultural mandate. It wasn’t just a cute slogan; it was baked into the company’s operational DNA through mechanisms like the 45-Minute Rule (new employees should be productive within 45 minutes) and a culture that celebrated shipping code over endless debate. The philosophy was seductive: speed creates competitive advantage, and competitive advantage equals survival. Move fast, iterate based on real-world feedback, don’t get bogged down in perfectionism. For early-stage startups with limited resources and existential pressure, this made perfect sense. You had three months of runway. You didn’t have time for a 47-slide deck about potential edge cases. Then 2014 happened. Mark Zuckerberg announced that Facebook was officially shifting from “Move fast and break things” to “Move fast with stable infrastructure”. It was portrayed as maturation, a philosophical evolution. The company was growing up. It had billions of users. Breaking things now meant breaking things for billions of people. The tech industry nodded approvingly. “Yes, we’ve moved beyond that phase,” everyone seemed to agree. LinkedIn profiles stopped listing “fast-moving” as a core company value (or at least became more coy about it). Medium articles were written about the death of disruption. Ethics became a consulting category. But ask a founder how they actually operate, and you’ll often hear something different.

The Persistence Paradox

Here’s what I suspect is happening: the “move fast and break things” philosophy didn’t die because it works—at least in a certain context and for a certain phase of company growth. What changed is that we became uncomfortable saying it out loud. Instead, startups today practice a kind of philosophical gymnastics. They’ll tell you they’re “customer-obsessed” and “data-driven” while simultaneously shipping features that haven’t been tested with actual users. They’ll promise “sustainable growth” while maintaining burn rates that would make a venture partner weep. They’ll talk about “responsible innovation” while using feature flags to quietly A/B test changes that might have regulatory implications. The infrastructure changed. The underlying values? Not as much as we think. Consider what’s actually happening in most startup engineering environments: Compressed timelines. Series A companies still operate with the assumption that shipping now and fixing later is better than shipping later and being perfect. The timescale has shifted (you have slightly more than three months), but the principle remains. Continuous deployment. Feature flags have become ubiquitous. You can deploy code without releasing it to users, which allows teams to move faster while managing risk. The mechanics are more sophisticated, but the philosophy—get code into production quickly—is the same. Blameless post-mortems. Most startups now have some version of this culture where breaking things isn’t necessarily a career-ending event if you fix it and learn from it. This encourages risk-taking in the name of speed. The celebration of execution over perfect planning. I’ve been in pitch meetings where founders are praised for “shipping fast” and criticized for “overthinking.” The code-wins-arguments mentality is still alive; it’s just called “test and learn” now. None of this is inherently wrong. The question is: are we doing this consciously, or are we sleepwalking into the same dynamics we claimed to move past?

The Anatomy of the Relapse

Let’s zoom into how this actually manifests. Here’s the pattern I see repeatedly:

1. Ambitious timeline set by fundraising pressure
2. Engineering team makes implicit trade-offs (speed over polish)
3. The trade-offs feel temporary at the time
4. Some things break
5. Post-mortems happen
6. Lessons are documented
7. Timeline pressure increases again
8. Cycle repeats

What’s interesting is that the second cycle doesn’t feel like repeating the first one. It feels like a new situation with new constraints. And technically, it is. But the underlying dynamic—prioritizing time-to-market over structural stability—persists. Here’s a concrete example from the payment processing world: a fintech startup I know processes transactions with a fallback system that’s never actually been tested in production under load. Does the team know this? Yes. Will they fix it? Probably. When? When either (a) they hit the load threshold, or (b) the pressure from fundraising or partnerships forces the issue. Until then, they’re living in the “probably fine” zone, which is where most startups actually operate. This isn’t malice. It’s not even negligence exactly. It’s a rational response to genuine constraints. You have limited time, limited money, and unlimited things you could build. You choose what to optimize for, and in startup environments, speed usually wins.

The Unspoken Algorithm

Here’s what I think is really happening: most startups operate according to an implicit algorithm that looks something like this:

IF (we_have_funding_runway) THEN
    PRIORITIZE shipping_new_features
    TOLERATE technical_debt
    ACCEPT calculated_risks
ELSE IF (we_need_revenue_or_partnership) THEN
    ACCELERATE shipping_timeline
    COMPRESS testing_windows
    INCREASE risk_appetite
END IF

This algorithm doesn’t appear in your engineering handbook. It’s not documented in your confluence wiki. But it’s been implemented in every prioritization meeting, every sprint planning, every “we’ll do this the right way next quarter” conversation that keeps getting punted. The “move fast and break things” ethos persists because the underlying conditions that created it haven’t changed much. You still have more ideas than time. You still face the “get to product-market fit before cash runs out” imperative. You still need to prove that your unit economics work before you can invest in the infrastructure that would make everything stable. What changed is the packaging. We now have better tools (feature flags, canary deployments, chaos engineering) and better language (“moving fast with stability” instead of “breaking things”). But the fundamental trade-off—speed versus stability, progress versus caution—is still the central tension of startup life.

Where the Philosophy Breaks Down

Now, here’s where I think the critics have a legitimate point: the speed-over-stability playbook works great until it doesn’t. In 2014, when Zuckerberg announced the shift to “move fast with stable infrastructure,” that wasn’t just a philosophical musing. It was a necessary evolution. You cannot run a system serving billions of people with the same casualness you bring to a college networking app. The cost of breaking things scales with your user base, your criticality in people’s lives, and your regulatory exposure. For a B2B SaaS company processing customer payments, breaking things can mean money disappearing. For a healthcare app, it can mean data loss or safety issues. For a financial services company, it can mean regulatory action. The uncomfortable truth: the “move fast and break things” philosophy works for startups in certain categories (low-stakes, high-tolerance-for-disruption, B2C consumer apps) and fails catastrophically in others (fintech, healthcare, infrastructure, anything regulated). Yet—and here’s the persistent irony—startups in the high-stakes categories often still practice speed-first development early on. They just do it with more guilt and more post-hoc apologies to compliance.

The Modern Iteration: Move Fast with Guardrails

So if “move fast and break things” is dead but not actually dead, what’s the current incarnation? I’d call it: “Move fast with guardrails.” It’s the synthesis of the old philosophy with new constraints. Here’s what it looks like in practice: Better observability. You break things, but you detect the break in seconds instead of finding out from users. Most modern startups have comprehensive logging, monitoring, and alerting. When something goes wrong, you know immediately. Progressive rollouts. Feature flags let you release to 1% of users first, then 10%, then everyone. You maintain the speed of deployment while reducing the blast radius. Testing automation. Unit tests, integration tests, end-to-end tests, load testing. None of these are novel, but they’ve become table stakes in most professional engineering environments. Incident response procedures. Blameless post-mortems, root cause analysis, action items. When things break, there’s a structured process to learn and improve. Cross-functional reviews. Before you ship that feature, it goes through product, design, security, sometimes legal. This slows things down slightly compared to just shipping, but prevents certain categories of breaks. This is the current synthesis. It’s not the revolutionary “break things fast” of the early Facebook days. But it’s also not the “move slowly and carefully plan everything” approach that would make a large enterprise comfortable. It’s a practical compromise. And like most compromises, it contains the seeds of ongoing tension.

Why It Persists (A Hypothesis)

Here’s my theory about why this philosophy has such staying power, even when we collectively agree it’s problematic: It produces results, at least initially. A startup that moves fast and ships more features than competitors tends to gain market share. This is empirically true. The question is whether it’s true at what cost, but in the short term, the results are visible. Incentive structures reward it. Venture capital timelines, fundraising milestones, growth targets—they all reward speed. If you move fast and gain users, you can raise more money. If you move slow and build perfect systems, you run out of money, regardless of how elegant your architecture is. The failure costs are externalized. If your fast-moving startup breaks something, who pays? Sometimes it’s your users (they lose data), sometimes it’s your employees (they work weekends fixing stuff), sometimes it’s your investors (they lose their stake). But from a decision-making perspective, the costs feel distant when you’re writing the code. It’s deeply embedded in culture. This isn’t just about individual decisions. It’s about hiring, about which engineers get promoted, about which teams get resources. A culture that rewards “velocity” and “execution” will naturally attract and promote people who move fast. Over time, this becomes the organizational norm. The alternative sounds boring and ineffective. “Let’s move carefully and thoroughly” is hard to rally a startup around. “Move fast and break things”—even when we don’t say it out loud—carries an energy and urgency that makes sense in a competitive environment where capital is scarce and attention spans are limited. So the philosophy persists, not because people are reckless, but because it’s embedded in the fundamental incentive structure of how startups work.

A Mermaid Diagram That Explains More Than It Should

Let me visualize the current state of affairs:

The diagram shows the path: most startups begin with speed pressure, and diverge based on whether they operate in high-stakes or low-stakes categories. Some stay in the “move fast with guardrails” zone indefinitely. Others are forced to mature when regulatory or scale pressures mount.

Code Example: Implementing the Move-Fast Mindset

Here’s what this actually looks like in code. Let’s say you’re building a user notification system. The “move fast” approach would look something like:

# The move-fast version: ship quickly, handle edge cases later
def send_notification(user_id, message):
    try:
        notification = Notification.create(
            user_id=user_id,
            message=message,
            timestamp=datetime.now()
        )
        # Send immediately to all channels
        send_to_email(user_id, message)
        send_to_sms(user_id, message)
        send_to_push(user_id, message)
        return notification
    except Exception as e:
        # Log it and move on
        logger.error(f"Failed to send: {e}")
        return None

The modern “move fast with guardrails” approach:

# The modern version: move fast but with safety features
def send_notification(user_id, message):
    # Feature flag: can disable this entirely
    if not feature_flag_enabled("notifications.enabled"):
        return None
    try:
        notification = Notification.create(
            user_id=user_id,
            message=message,
            timestamp=datetime.now(),
            # Track versions for rollback
            version="1.2.3"
        )
        # Progressive rollout: only send to percentage of users
        if should_send_to_user(user_id):
            # Try email, fall back gracefully
            with tracer.span("send_email"):
                try:
                    send_to_email(user_id, message)
                except Exception as e:
                    logger.error(f"Email failed: {e}", extra={
                        "user_id": user_id,
                        "notification_id": notification.id
                    })
                    # Continue anyway, don't block the whole request
            # Same for SMS and push, with monitoring
            with tracer.span("send_sms"):
                try:
                    send_to_sms(user_id, message)
                except Exception as e:
                    logger.error(f"SMS failed: {e}")
            # Emit metrics for observability
            metrics.increment("notifications.sent")
        return notification
    except Exception as e:
        logger.error(f"Critical notification failure: {e}")
        # Have a fallback queuing system
        enqueue_for_retry(user_id, message)
        return None

The second version takes longer to write. It requires more infrastructure (feature flags, monitoring, tracing). But it embodies the “move fast with guardrails” philosophy: you’re still shipping quickly, but you’ve added mechanisms to detect and contain failures. This isn’t revolutionary. But it’s the difference between 2014 Facebook and 2026 startups.

The Uncomfortable Questions

Here’s what I think we should actually be asking: Are we choosing speed consciously or defaulting to it? Many startups move fast not because they’ve decided it’s the right trade-off for their situation, but because they haven’t actively decided anything else. It’s the default. What are we actually breaking? “Breaking things” sounds cool in theory. In practice, it means different things: performance degradation, data loss, security vulnerabilities, poor user experience, burned-out employees working weekend incidents. Which of these are we actually willing to accept? Is our guardrail system actually sufficient? Feature flags and monitoring are good. But they don’t prevent the break; they just make it detectable. If you’re consistently breaking things, even with good guardrails, maybe the underlying development process needs to change. When should we shift gears? There’s probably a right time to move from “move fast and break things” to “move fast with stability” to “move carefully and build right.” Most startups don’t consciously make this transition; it’s forced on them by circumstances. Are we aligning speed with impact? The modern critique of “move fast and break things” isn’t really about speed. It’s about impact. A fintech company that moves fast and breaks payment processing is creating real harm. A B2C app that moves fast and breaks notifications is creating minor annoyance. These should have different speed tolerances.

A Personal Take

I think “move fast and break things” hasn’t really gone away; it’s just been repackaged for a more conscientious era. We’ve added tools and processes that make speed feel safer, but the underlying philosophy—prioritize time-to-market over structural perfection—persists because it works. The question isn’t whether startups should move fast. Of course they should; it’s a genuine competitive advantage. The question is: fast at what and with what consequences? A startup moving fast at feature development while ignoring security architecture is making a bet. A startup moving fast at user growth while ignoring retention and unit economics is making a different bet. A startup moving fast at hiring while ignoring culture is making yet another bet. These are all valid bets in the right context. What worries me is when teams make these bets implicitly, without acknowledging the trade-offs. The best version of “move fast” isn’t “move fast and break things.” It’s “move fast and own the consequences.” Move fast, but know what you’re risking. Move fast, but have mechanisms to detect problems. Move fast, but be ready to shift gears when the rules change. That’s actually what most mature startups are doing now. They’re not following the 2008 Facebook playbook. But they’re not exactly playing it safe either. They’re operating in the productive tension between speed and stability, constantly recalibrating based on feedback. The philosophy didn’t die. It evolved. And that might actually be the right answer.