InsightsWorkflow Ownership
Workflow Ownership

The Switching Cost Nobody Calculates

Staying on a tool that isn't working has a price. So does leaving it. Most founders only ever price one of them.

Savannah O'Byrne·May 2026·7 min read

Ask a founder what it would cost to leave the platform she has outgrown, and she can usually answer within a minute. The migration. The re-training. The risk of losing data in the export. The weeks of double-running the old system and the new one so nothing falls through. She has priced that cost carefully, because it is the cost that scares her.

Ask her what it costs to stay, and the answer is much harder to get. Not because the cost is smaller. Because nobody ever asked her to add it up.

The cost that never shows up on an invoice

The subscription fee is the only cost of staying that appears anywhere official. It is a fixed number, billed monthly, easy to point at. Everything else (the workaround she built to make the tool do something it was not designed for, the manual step she added because the automation kept failing on edge cases, the hour a week she spends translating between this tool and the three others it does not talk to), none of that appears on an invoice. It appears in her calendar, her attention, and her sense of always being slightly behind.

That is the asymmetry. Switching costs are visible, one-time, and easy to fear. Staying costs are invisible, recurring, and easy to normalize. A founder will avoid a two-week migration to save herself two hours a week of friction forever, because the two weeks feels like the bigger number, even when it is not.

Switching costs are visible and one-time. Staying costs are invisible and forever. Most founders only ever price the first one.

Why the comparison never gets made

Part of the reason is that staying costs are diffuse. They do not arrive as a single bill. They arrive as a dozen small frictions spread across a week, each one too minor to justify a project on its own. Individually, none of them feel like a decision point. Collectively, they are the reason the business has not changed direction in three years.

The other reason is that switching feels risky in a way that staying does not, even when staying is the riskier choice. A migration has a clear, visible failure mode, something breaks during the transition, and everyone notices. Staying has a slow, invisible failure mode, the workaround pile grows, the manual steps multiply, the workflow becomes marginally less resilient every quarter. Nobody notices the day it happens, because it happens a little at a time.

What an honest comparison looks like

An honest comparison does not ask whether switching has a cost. It obviously does. It asks whether the cost of switching, paid once, is smaller than the cost of staying, paid every week for the next several years. For a workflow that is genuinely stable and central to how the business runs, that math is not close.

  • Add up the workarounds: every manual step that exists because the tool does not do something natively.
  • Add up the re-entry, every place the same information gets typed twice because the tool does not connect to what comes next.
  • Add up the babysitting: every automation that only works if someone checks on it.
  • Multiply by how many more years the business plans to run this way.

That number can become material over two or three years. It should be compared against the cost, risk, disruption, maintenance responsibility, and expected value of keeping, connecting, replacing, protecting, or building, not treated as automatic evidence for a rebuild.

Diagnosis is where that invisible number becomes visible. Observing where workarounds live can turn vague friction into evidence that can be compared honestly against the cost, risk, and responsibility of changing the system.

Start Here

Start with the business problem.

A free Systems Fit Conversation determines whether the problem, operating context, and readiness justify a paid Business Systems Diagnosis. The diagnosis creates a decision asset; it does not assume that implementation is the answer.

Describe the Problem →
Start with a clear scope

Tell us what you need built.

Share the project, problem, or workflow you want help with. We'll review the details personally and respond with questions or a written quote when the scope is clear enough.