The Software You Depend On Has an Owner. Their Decision Never Shows Up on Any Spreadsheet.

One morning a studio found out that a voice-animation tool it had bought years ago, a one-time payment for a lifetime license, had turned into a subscription costing tens of thousands of dollars a year. Same software, same screen, same work. The only thing that had changed was the mind of the person who owned that tool. And that mind wasn’t written anywhere, not in the budget, not on the roadmap. Overnight, a cost they thought they had settled on paper reopened.

Don’t read that as a single piece of bad luck. Around the same days three more stories crossed my path, none of them alike, all of them pressing on the same nerve. Managers who thought they could swap out their own teams for near-free with AI froze when the end-of-month invoice landed. A gaming platform hinted it could reclaim the digital games people had paid real money for if they hadn’t logged in for a while. Another company was in the news for subscriptions that were deliberately made hard to cancel. Different worlds, different scales, but underneath, always the same sentence: the thing you use has an owner, and that owner can turn the rules any day, in any direction they like.

We engineers and product builders love to put one thing on top of another. We call someone’s library, we lean on someone’s cloud service, we fire requests at someone’s model, and after a while we forget the ground underneath. We build floors on it as if it were our own land. But the ground under us is usually rented. And the strangest part of rent isn’t the number written in the contract. It’s that one side can change the contract.

“It won’t happen if you pick a good provider”

The objection I hear most often is this: these things happen to careless people. Pick a solid, established provider that everyone uses, and you’ve covered yourself. Tie yourself to some small, obscure tool and of course you’re taking a risk, but standing behind the giants is safe.

I respect that objection, because it carries a grain of truth. A well-established provider really is less likely to vanish overnight. But the question is framed wrong. The point isn’t whether the provider will still exist tomorrow. The point is whether, while it goes on existing, it will decide in your favor or its own. And being large doesn’t mean it will decide in your favor. If anything, being large lowers its need to negotiate with you at all.

The companies that doubled a price, turned a lifetime license into a subscription, or shut off a free tier one morning were mostly not small and desperate. On the contrary, they were large enough to make that call comfortably, because they were sure they had pulled you far enough in. Once dependence is set, the provider’s size is not your safety net, it’s their leverage. The higher the cost of leaving, the more comfortably they raise your price. You don’t even need bad intent to explain it. It’s the most natural reflex a business has.

The invisible rent

Here’s the real issue: this risk has no place on any spreadsheet.

Think about what you actually estimate when you plan a piece of work. How many days it will take, how many people will work on it, which library you’ll install. Maybe you even add the license fee as a line item. But nobody opens a line that says “if this tool triples its price three years from now” or “if this service claws that feature back.” Because that line has no number. You don’t know when it will happen, or whether it will happen at all. And because it’s uncertain, you act as if it doesn’t exist.

That’s exactly where the danger sits. An invisible cost is dangerous not because it goes unmeasured, but because it never enters the table in the first place. A while ago, writing about prioritization, I argued that the most honest box in RICE is Effort: writing down what a piece of work will cost you broke the “this’ll take two days” lie. But I’ll admit it, most of the time I only wrote my own labor into that box. The chance that a tool I depend on might one day back me into a corner, I never put in Effort at all. Yet the most expensive labor is not the labor you spend. It’s the labor someone else can decide to spend on your behalf.

The real cost of a piece of work is not just building it. The cost of leaving it, migrating off it, getting free of that dependence, is part of the cost too. And if you don’t think about it while you’re building, then on the day you need to get out, the provider sets the price, not you.

The sly part is how this cost grows quietly over time. The longer a dependence runs without trouble, the more you trust it, the more you build on top of it. Past a certain point you stop even seeing it as a dependence, it’s just part of you now. But the truth is the opposite: the tool you’ve leaned on longest, trusted most, is the one that’s most expensive to leave. Because that’s where the roots go deepest. The provider knows this better than you do. It saves the price hike for the moment you’ve become most comfortable, most blind to it.

AI didn’t make this cheaper, it made it deeper

Lately everything has gotten sharper. AI made producing cheaper, that’s true. It has never been this easy to get an idea working. But that same ease tied you, without your noticing, to someone’s model, someone’s servers, someone’s meter.

Remember those managers who froze at the invoice. Their mistake wasn’t using AI. Their mistake was failing to see that the only thing that got cheaper was starting. Each request is a few cents on its own. But those cents pile up, not on a meter you’re watching, but on a meter someone else is spinning on your behalf. As the unit cost falls, the total cost climbs quietly, and you’re not the one setting the speed of that meter. The cheap start was the bait inviting you into an expensive dependence.

There’s an old line: ride a borrowed horse and you’ll be back on your own feet sooner than you think. Someone else’s horse carries you a certain distance, you’re fast, you don’t tire, you’re enjoying it. But the horse isn’t yours. The day the owner pulls the reins, you’re left standing wherever you happen to be. In the age of AI we’ve all been riding someone else’s horse for a while now, and most of us never once stopped to think about whose horse it is.

Now let me trip up my own argument

Someone who’s read this far might think: if dependence is this dangerous, then don’t tie yourself to anything, do it all yourself. Build your own infrastructure, write your own tools, need no one.

This is one of the answers that sounds strong but has misled me most over the years. Because there’s no such thing as independence. Write everything yourself and this time you’re dependent on the owner of the dozens of lines you wrote, the operating system you run on, your language, your compiler. There’s no escape. And “I’ll do it myself” carries its own cost: every wheel you reinvent is a weight you hoist onto your back and can never set down again.

More than that, the thing you think is free has an owner too. Behind that open-source library you stare at day and night, there is often a single person, getting nothing in return, running until they’re spent. The morning that person says “I can’t do this anymore” and walks away, the ground you thought was solid slips too. Free doesn’t mean ownerless. It just means someone else is paying the bill for now.

So the solution isn’t independence, because that isn’t possible. The solution is to choose your dependence knowingly. To know, from day one, what you’re leaning on, whose ground it is, and what it will cost you if one day you have to get up and leave. Not to pretend the risk away, but to name it.

Knowing the ground

In practice I’ve boiled this down to a few questions, and I ask them of myself now before I start any work. Who owns this tool? If it doubles its price tomorrow, does my work stop or keep going? If I have to get out of here, can I take my data, my work, my labor with me, or does all of it stay behind their door? If I don’t know the answers to these three, I think twice before building a floor on that ground.

None of this forbids depending on things. I too do my work every day leaning on other people’s tools, there’s no other way. But now, when I lean, I know the ground is rented. Being a tenant isn’t the problem. Forgetting you’re a tenant, knocking down walls, launching into expensive renovations, that’s the problem. One of the quiet parts of owning a product or a piece of work is exactly this: mapping the land you stand on but don’t own.

Engineering management is mostly remembered for the bright calls. But most of the job is this kind of bookkeeping that nobody applauds. Knowing what you depend on, knowing whose hand that dependence is in, and having already thought through what you’ll do the day that hand tightens. The software you depend on has an owner. At the very least, you need to know who that owner is.