There is a particular feeling you get when something you rely on every day gets acquired, and it is not excitement. It is the small, cold drop in the stomach you feel when a good local pub gets bought by a chain. The sign might not change for a year. But you know, the moment you read the news, that the thing you liked about it is now on a clock.
I have been thinking about this all week because the developer tooling world is doing what it does every spring, which is consolidate. The funding climate has turned since last year, the easy money has dried up, and a lot of small companies that built genuinely lovely tools are discovering that "genuinely lovely" and "sustainable business" are not the same sentence. So they get bought. Sometimes by a giant who wants the team, sometimes by a giant who wants the market, occasionally by a giant who actually wants the product. You can usually tell which from the wording of the announcement, if you have read enough of them.
the three flavours of acquisition
The blog post always says the same thing. "We're excited to join forces." "Nothing changes for our users." "This lets us invest more in the product you love." I have read this post, almost verbatim, for tools I depended on, perhaps a dozen times now, and I have learned to read past it to the structure underneath, because the structure tells you what actually happens.
The first flavour is the acqui-hire. They wanted the people, not the thing. The product is a rounding error in the deal. In this case "nothing changes" is technically true for a while because nobody is left to change it, and then eighteen months later there is a sunset email and a data export deadline. The tell is when the announcement spends three paragraphs on the team's "journey" and one sentence, near the bottom, on the product.
The second flavour is the absorption. They wanted your product because it competes with, or completes, theirs. Here the product survives but loses its soul. The sharp opinionated edges that made it good get sanded off to fit the parent's portfolio, the pricing gets "aligned", which always means up, and the thing that made it a joy, usually a refusal to do some obvious-but-wrong thing, quietly gets done. The tell is any phrase about "the broader platform".
The third flavour, the rare good one, is when a larger company genuinely wants the product to keep being itself, and has the discipline to leave it alone. This happens. It is not a fairy tale. But it is rare enough that betting on it is unwise, and even when it happens, the founders who cared about leaving it alone tend to leave, their earn-out done, and their replacements have a spreadsheet to answer to.
what I actually do about it
For a long time my answer to all this was a sort of fatalism. Everything gets bought, everything decays, build nothing on anything you do not control. That is a recipe for using nothing and shipping nothing, so I have softened.
What I do now is grade my dependencies by how much it would hurt to lose them, and how easily I could leave. A tool with an open format I can export, a documented API, or an open-source core is one I can adopt wholeheartedly, because the acquisition that ruins it cannot trap me. I will have to do some work to migrate, but the door is not locked. A tool that holds my data in a proprietary shape, with no export worth the name, is one I keep at arm's length no matter how good it is, because the acquisition that ruins it ruins me with it.
The practical version is boring and I do it anyway. I check, before I commit to anything, whether I can get my data out in a format I can use elsewhere. I keep an eye on whether the format is something I could reimplement against if I had to. And I treat any tool with a single small company behind it as a tool that will, eventually, have something else behind it instead, because in this market it will.
There is a temptation, when you spot all this coming, to over-correct and self-host everything. I went through that phase. For a while I ran my own version of every service I could, on the theory that nobody could take from me what I already controlled. It was exhausting and, frankly, worse. I became the single point of failure, the on-call engineer for my own toothbrush, and the quality of the things I ran myself was reliably below the things professionals ran for me. The lesson there is that independence has a running cost, and you should pay it only where the dependency actually matters. Self-hosting your critical data store is wisdom. Self-hosting your calendar because a calendar company might get bought is just a hobby with extra steps, and you will resent it within a month.
the part that is not cynicism
I want to be clear that none of this is anger at the founders. Building a good tool and then watching the economics fail to support it is genuinely sad, and selling to someone with deeper pockets is often the responsible thing to do for everyone involved, including the users, for a while. I have used tools that only existed at all because someone took an acquisition that kept the lights on. The alternative was often nothing.
So when I read this week's round of announcements, I am not furious. I am just doing the quiet inventory I always do. Which of my dependencies just changed owners. How locked in am I. What is my exit if the new owner turns out to be the absorbing kind. It takes ten minutes and it has saved me a genuinely bad year more than once.
The tool I rely on most that got swept up in all this still works exactly as it did last week. The sign has not changed. But I have started looking, quietly, at what else is on the shelf, because the clock is running now, and the worst time to look for the exit is the day they finally lock the door.