What Happens to Your Stack When a Vendor Gets Acquired

A vendor you depend on gets acquired, and within a year the thing you relied on is worse, more expensive, or gone. This is not a rare event. It is the normal life cycle of the tools you build on. A bigger company buys the small one you liked, the founders leave, the roadmap you cared about gets absorbed into a suite you did not want, and the generous pricing that hooked you evaporates. If a single acquisition can break your business, you built on rented land. The fix is not to avoid every acquirable vendor. It is to know which dependencies would actually hurt and to keep an exit ready for those.

What actually happens after an acquisition?

The pattern repeats so reliably you can plan around it. Watch for these in order.

Pricing changes first. The free tier that got you in gets cut, capped, or killed, because the acquirer needs to justify the purchase. The generous plan becomes the entry plan.

The roadmap dies next. Whatever made the tool special was often the thing the acquirer did not buy it for. Your favorite feature stops getting attention. Bug fixes slow. The team that built it moves on or gets reassigned.

Integration pressure follows. The acquirer wants you inside their whole ecosystem, so the standalone product gets nudged toward their platform. Now leaving costs more than it did before.

Sometimes the whole thing sunsets. The acquirer bought the customer list or the technology, not the product, and shuts it down with a migration deadline you did not ask for.

None of this is malice. It is just what happens, and pretending your critical vendors are immune is how you get surprised.

Which dependencies actually put you at risk?

Not all of them. A tool you could swap in an afternoon is not a risk no matter who buys it. The dangerous ones share three traits.

They hold your data in a form only they can read. If leaving means losing history or reformatting everything, you are exposed. This is why every vendor needs an exit plan before you depend on them, not after.

They sit deep in your critical path. If the tool going away stops you from serving customers or shipping product, it is load-bearing. A load-bearing rented dependency is the one to worry about.

They have proprietary lock-in you accepted for convenience. Serverless functions, provider-specific databases, magic platform features. The deeper the integration, the higher the switching cost, which is exactly why serverless is the deepest lock-in there is.

Rank your vendors by those three. The ones that score high on all three are where acquisition risk becomes business risk.

How to protect against acquisition risk

You do not need to self-host everything. You need to be moveable on the things that matter.

Own the layers that are cheapest to own and most painful to lose. Your database, your deploy pipeline, your DNS, your backups. When those sit on infrastructure you control, no acquisition can touch them. That is the whole reason I keep my database on a box I own instead of a managed service that could be bought and repriced.

Keep exports current for the vendors you cannot replace yet. If the tool holds important data, pull a full export on a schedule so an overnight shutdown notice is an inconvenience, not a catastrophe.

Prefer vendors built on open standards. If a tool speaks a protocol or format that other tools also speak, swapping it is cheap. If it speaks only its own dialect, you are betting your continuity on their independence.

Know your escape route before you need it. For every critical vendor, be able to answer: if this disappeared in ninety days, what would I do? If you cannot answer, that is the work, and it connects to the broader discipline of spotting lock-in before you sign.

The mindset that keeps you safe

Assume every vendor you rely on will eventually be acquired, repriced, or retired. That is not cynicism, it is the base rate. Build so that any single one going away is survivable.

For me that means owning the foundation and renting only the replaceable edges. The core of my stack runs on servers I control, which is the entire point of owning your stack: acquisitions happen to other people's companies, not to your infrastructure. You can put the load-bearing pieces, your database, your deploys, your backups, on a box you hold at HostSSH, and then the next big acquisition headline is just news, not an emergency.