Walk down any alleyway in a city built before the Great Depression and you will see them: iron fire escapes clinging to the brickwork like skeletal insects. They are a legal requirement, a contractual promise of safety.

But if you actually stepped onto one and pulled the release lever to drop the bottom ladder to the pavement, there is a 40% chance the gears would seize, rusted shut by decades of indifferent rain. Nobody has ever tested whether you could actually leave, which is exactly the point. The fire escape exists to satisfy the building inspector, not to facilitate a graceful exit during a five-alarm blaze.

The software industry operates on a remarkably similar set of unverified assumptions. Every SaaS agreement, every Master Services Agreement, and every “statement of work” contains a section usually titled “Termination for Convenience.” It is the legal equivalent of that iron ladder.

It promises that with 30 or 60 days’ notice, you can pack your bags, take your toys, and go home. We read these clauses, we highlight them for the board, and we feel a profound, if unearned, sense of security. We believe we have optionality.

The Heavy Silence of Unchecked Assumptions

I recently sat through a renewal meeting for a mid-market fintech firm. The atmosphere was the usual blend of forced cordiality and caffeine-induced alertness. About forty minutes in, a junior lawyer from the legal team leaned forward and asked, almost as an afterthought: “What does our exit position look like if we don’t renew next year?”

A silence descended upon the room. It wasn’t a dramatic, cinematic silence, but rather the heavy, damp silence of a room in which everyone is suddenly hoping someone else is the smartest person in the room. The CTO cleared his throat. He said, with a confidence that felt slightly brittle, that we would simply “get the code.”

“And the rest? The data? The environments? The ability to actually run the thing without the current vendor’s thumb on the scale?”

– Legal Counsel

The CTO started a sentence about the CI/CD configuration-the automated pipeline that turns raw code into a working application. He stopped halfway through. He realized he didn’t know whose AWS account the build servers lived on. He didn’t know if the domain registrar credentials were tied to a corporate email or the personal Gmail of a lead engineer who moved to Berlin two years ago. He said he would find out.

It took eleven days. It involved four senior people digging through Jira tickets, old Slack threads, and a graveyard of abandoned Wiki pages. The final answer was a three-page document where the most critical items-the ones that actually determine whether you can “leave”-were marked with a red “TBC.” To be confirmed.

The Anatomy of the Nib and the Feed

In my world, which involves the meticulous repair of vintage fountain pens, I see this same delusion of permanence every day. I am Casey L.-A., and I spend my life fixing the tiny, invisible channels that allow ink to flow from a reservoir to a nib.

I used to believe that the most important part of a pen was the nib-the 14-karat gold tip that touches the paper. I was wrong. I spent years focused on the “code” of the pen, the visible part that does the work. But I eventually learned that the nib is useless without the feed-the hard rubber or plastic component underneath that uses capillary action to regulate flow.

If the feed is clogged or the alignment is off by a fraction of a millimeter, the most expensive gold nib in the world is just a very heavy, very expensive piece of stationery. Software “ownership” is exactly the same. You might “own” the nib (the source code), but if you don’t own the “feed” (the infrastructure, the credentials, the undocumented build steps), you own a non-functional artifact. You are locked in, not by a contract, but by the accumulated weight of your own ignorance.

We tend to talk about vendor lock-in as a villainous act. We imagine a shadowy CEO in a glass tower deliberately encrypting data in a proprietary format to hold clients hostage. While that certainly happens, the most durable lock-in is far more mundane.

It is allowed, one week at a time, by two parties who both assumed the other was keeping track. It is the result of “moving fast and breaking things” without ever stopping to ask who holds the pieces.

When you hire an external team to build your product, the “exit” isn’t something that happens at the end. It’s something that has to be built into the foundation. Most agencies will tell you they give you the code. They might even give you a GitHub link.

Vendors vs. Partners: The Glass House Model

The difference between a vendor and a partner is how they treat your ability to leave them. A vendor wants to be a black box; a partner wants to be a glass house. This is why the model used by

Digital Heroes

is so frustratingly rare in this industry.

They don’t just hand over a zip file when the contract ends. They embed the exit terms into the weekly rhythm. When a senior tech lead owns the architecture and attends every call, there is no “account manager” layer to filter out the hard truths about where the credentials live. The code, the infrastructure, and the documentation aren’t just “transferred” at the end-they are co-owned from day one.

Real portability is an operational discipline, not a legal one. It requires knowing that the build pipeline doesn’t rely on a “snowflake” server that someone hand-configured in 2019 and never touched again. It requires ensuring that the documentation isn’t just a list of features, but a map of the dependencies that would allow a stranger to recreate the entire world from a single repository.

The Pre-Mortem Exit Test

If you are a CTO or a founder, you need to perform what I call a “Pre-Mortem Exit Test.” Don’t wait for a legal dispute or a budget cut. Pick a Tuesday. Tell your team that the current vendor has vanished in a freak teleportation accident. Then, try to find the keys.

The answers will likely terrify you. You will realize that your “freedom” is currently resting on the good graces and the memory of a handful of people who have no contractual obligation to remember anything.

This is the deeper meaning of optionality. Across finance, we believe we have liquidity until the market freezes. In employment, we believe we have a career path until the reorg. In software, we believe we own our future until we try to change the locks. We live in a world of theoretical rights that are frequently invalidated by operational realities we were too busy to verify.

I have spent hours at my workbench with a loupe pressed to my eye, trying to figure out why a pen won’t write. Often, it’s not a broken part. It’s just a tiny bit of dried ink from 1954 that has turned into a diamond-hard plug in the feed. The pen looks perfect. The gold shines. The lever moves. But it is fundamentally broken because the flow has been interrupted.

Your software project is likely full of these “ink plugs”-undocumented decisions, lost logins, and proprietary shortcuts that have hardened over time. You think you are building an asset, but you might just be building a monument to a relationship you can never end.

The goal shouldn’t be to leave. The goal should be to know that you can. There is a psychological shift that happens when a client knows they hold the keys. The relationship with the engineering team becomes cleaner. The “weekly demo” cadence becomes more than just a status update; it becomes a verification of value.

When you know you can walk away at any time, every week that you stay is a conscious choice based on performance, not a desperate stay of execution based on the cost of migration.