Move fast and break things. Until the thing is someone's money.

Mark Zuckerberg gave a generation of founders a licence, and most of them never read the small print. "Move fast and break things" was a brilliant operating principle — for the thing it was written for. It built one of the largest companies in history. It also quietly became the most misapplied sentence in technology, because thousands of founders heard the first half and ignored the context. Nowhere is that costlier than in fintech.

Here's the uncomfortable part: the mantra is right. Speed wins. The problem is that fintech founders copy it instead of adapting it, and in fintech, the things you break aren't features. They're someone's money, someone's trust, and your own standing with a regulator who has never once been impressed by how fast you shipped.

Where the mantra came from, and why it worked.

The phrase comes from a specific world: an ad-funded social network, where the product was free, the stakes for any single user were low, and almost everything was reversible. Ship a bad feed change and the worst case is an embarrassing week and a rollback. The cost of being wrong was low, the cost of being slow was high, so the maths was obvious: move fast, break things, fix them in flight. Even Facebook later retired the phrase (it became "move fast with stable infrastructure") once the blast radius grew. The original was a tool for a low-consequence, reversible environment. That's the bit that didn't survive the copy-paste.

Fintech breaks differently.

Drag that operating model into a business that moves money and the failure modes change category entirely. When a fintech "breaks things", the things are real and the damage doesn't roll back cleanly:

• Money. A bug in a ledger, a payment, a balance or an interest calculation isn't a glitch. It's someone's rent, payroll or savings. You can redeploy the code; you can't always un-spend the money.
• Trust. People forgive a social app a clumsy redesign. They do not forgive a money app that loses their funds, even briefly. Trust is the entire product, and unlike code, it doesn't redeploy — once it's gone, it's gone.
• Security. A data breach in a fintech isn't an incident report, it's fraud, liability and front pages. The downside isn't bounded by a sprint.
• Compliance. Regulators don't grade on velocity. You cannot A/B test your way out of a KYC failure or move fast through an audit. "We were iterating" is not a defence.

The social network optimised for reversible, low-stakes change. Core fintech is the opposite: irreversible, high-stakes, and watched. Same mantra, completely different physics.

The real variable isn't speed. It's reversibility.

This is the reframe that makes the mantra usable. "Fast versus careful" is the wrong axis. The axis that matters is reversibility against stakes: how bad is it if this is wrong, and can you undo it? Get that lens right and the answer stops being "fast or slow" and becomes "fast here, deliberate there." Most of a fintech isn't the money core. The onboarding copy, the marketing site, the dashboard layout, the non-critical UI. That's all reversible, low-stakes, and you absolutely should move fast on it. The ledger, the payment rails, the balances, the KYC/AML flow — that's the irreversible core, and slow is fast there, because a single un-undoable mistake costs more than a year of velocity.

Adapt the mantra. Don't abandon it.

The lazy reading of all this is "fintech should move slowly". That's just as wrong as moving recklessly, and it kills as many fintechs. Death by caution, out-shipped by someone braver. The actual skill is engineering your way out of the irreversible corner so you earn the right to move fast. In practice:

• Map the blast radius first. Before any change, ask the only two questions that matter: how bad if it's wrong, and can we undo it? That sorts the work onto the matrix.
• Make as much reversible as you can. Feature flags, staged rollouts, canary releases, shadow mode, hard kill switches. Reversibility is something you build, not something you're handed, and the more you build it, the faster you're allowed to go.
• Put real guardrails on what stays irreversible. Four-eyes on money movement, automated reconciliation, immutable audit trails, pre-deploy checks on the ledger. Not bureaucracy — the things that let you sleep while still shipping weekly.
• Protect trust like the asset it is. A consumer app that breaks loses a session. A fintech that breaks loses the customer's money, their trust, and the regulator's patience (in that order), and you rarely get all three back.

Why this matters now.

Most fintech founders aren't reckless on purpose. They've absorbed a Silicon Valley operating system built for low-stakes software, and they apply it uniformly because nobody handed them the adapted version. The good ones aren't slower than their consumer-app peers. They're just deliberate about where the speed goes. They ship onboarding experiments daily and treat the ledger like the load-bearing wall it is. The founders who break things in fintech aren't the careful ones or the fast ones. They're the ones who never drew the line between the two.

How we use this at Product Pieces.

Most of the regulated-fintech teams we meet have one of two problems, and they're mirror images. Either they've over-rotated on caution and a deliverable roadmap has ground to a halt under the weight of process, or they've imported "move fast" wholesale and are one incident away from a very bad week. The work is the same in both directions: draw the line. We map the roadmap onto the reversible-versus-irreversible matrix, put the guardrails where the stakes are real, and free the team to move fast everywhere else. The board gets the speed it wants and the safety it needs, and, usually, a far clearer answer to "what should we actually be building next." That's the product function a regulated business needs: fast where it can be, deliberate where it must be, and honest about which is which.