The Announcement Drops and Your Stomach Drops With It
You open your email on a Tuesday morning and there it is: a cheerful blog post from the founders of the tool you’ve built half your work life around. They’re excited to announce they’ve joined [large company]. They’re not going anywhere. The product you love is only going to get better.
You’ve read this before. You know how it usually goes.
Acquisitions aren’t inherently bad for users, but they do change the game in ways that aren’t immediately obvious. The tool that got acquired was optimized for one thing: building something that solved your problem well enough that you’d pay for it. The company that acquired it is optimized for something different, something that may or may not overlap with what you actually need. Understanding that gap is the starting point for making smart decisions about what comes next.
What the Acquiring Company Actually Bought
Before you decide how worried to be, figure out what was actually purchased. Acquisitions happen for several distinct reasons, and each one has a different implication for your workflow.
Acqui-hiring is when the acquiring company primarily wanted the team. The product is incidental. When this is the case, the product either gets shut down (possibly quickly) or slowly starved of resources while the team gets absorbed into other projects. When Google acquired Sparrow, the beloved email app, in 2012, development effectively stopped. The team went to work on Gmail. Sparrow users had a functional app for a while, then nothing.
Technology acquisition means the company wanted specific IP or infrastructure. The product might survive in some form, but it will likely be folded into the acquirer’s existing suite. Figma’s attempted acquisition by Adobe before it was blocked by regulators would have been this type: Adobe wanted the technology and the design-tool market position.
Market acquisition is when a large player buys a smaller competitor to own more of the category. Here the product often survives longer, but it gets nudged toward serving the acquirer’s strategic goals rather than yours. Slack after the Salesforce acquisition in 2021 is still Slack, but watch where its development energy flows.
Read the announcement carefully. The language matters. “We’re joining the team” almost always means acqui-hire. “Our technology will power” means the product is going away. “We’re excited to bring our product to a wider audience” is the most hopeful framing, though still no guarantee.
The Six-Month Window Is Real
Product decisions made in the first six months after an acquisition set the trajectory for years. This is when roadmaps get reprioritized, when pricing gets reconsidered, when the independent pricing model (often generous, since the startup needed to grow) gets replaced by something that fits the acquirer’s tier structure.
This is also when the people who built the thing you loved start leaving. Founders often have retention agreements that keep them around for a year or two, but the engineers and designers who shaped the product’s character are under no such obligation. Watch LinkedIn. If the people who shipped the features you rely on are quietly updating their profiles, that tells you something.
You don’t need to panic in this window, but you should pay attention. Specifically: note which features stop getting updated, whether support response times change, whether the pricing page quietly shifts. These are early signals that are much easier to act on now than after you’ve waited eighteen months and the product has drifted far from what you need.
Building a Workflow That Can Survive Tool Churn
Here’s the practical reality: every piece of software you rely on will eventually be acquired, shut down, pivoted, or repriced out of your range. This isn’t pessimism, it’s just the economics of software. Building a workflow that’s resilient to this isn’t about paranoia. It’s about not letting someone else’s business decision derail months of your work.
A few principles that actually hold up:
Own your data in portable formats. If your work lives in a proprietary format that only exports cleanly into the acquiring company’s other products, you’re already behind. Wherever possible, use tools that export to open formats: plain text, markdown, CSV, standard image formats. This doesn’t mean you need to avoid good software. It means you should occasionally export your data and verify you could actually work with it somewhere else.
Separate your workflow from the tool’s specific interface. Many people build workflows around specific UI patterns of a tool rather than around the underlying task. When the tool changes (and it will), the whole workflow feels broken. If you instead build around the job to be done, specific tool optional, you can usually find a replacement that fits the framework even if the keystrokes are different.
Maintain a short list of alternatives. You don’t have to switch. You just need to know what you’d switch to, and roughly what the migration would cost in time and energy. Keeping that mental model updated takes maybe an hour a year and saves you from making a panicked decision when something does change.
Watch your dependencies. If the tool has an API you rely on, check the API’s status separately. Acquirers sometimes maintain the UI while quietly deprecating integrations. If other tools in your workflow connect to the acquired product, that’s where the breakage often shows up first.
The Case for Staying Longer Than You Think
It’s worth pushing back on the reflexive urge to migrate immediately after an announcement. Switching costs are real and often underestimated. The time to migrate your data, rebuild your integrations, retrain your muscle memory, and find and fix all the edge cases in a new tool can easily run into days of productive work lost. Sometimes more.
Some acquisitions genuinely improve products. When Notion acquired Cron and rebuilt it as Notion Calendar, the underlying product got significantly better infrastructure. When Atlassian acquired Trello in 2017, Trello continued operating independently for years. The track record is mixed, but it’s not uniformly bad.
The question to ask is: what would I lose by waiting six months to see how this plays out? If the answer is mostly nothing, wait. If the answer is that you’d be building deeper into a tool that might be fundamentally changing, that calculus shifts.
When It’s Actually Time to Leave
Some signals warrant moving immediately rather than waiting:
- The acquiring company has a direct competitor to the tool you’re using, and now owns both. One of them will get starved.
- Pricing changes have already been announced that make the tool untenable for your use case.
- The product is being folded into a suite you’d have to buy entirely, for features you don’t need.
- Key team members have left, and the product’s update cadence has already slowed.
- Your data format is becoming increasingly proprietary or locked to the acquiring company’s infrastructure.
If two or more of these apply, the signal is clear. The question becomes how to migrate gracefully rather than whether to do it.
Building the Portable Workflow, Practically
The goal isn’t a workflow that uses only open-source tools with no acquisition risk (you’d be trading one problem for another). The goal is a workflow where no single tool’s acquisition or failure causes catastrophic disruption.
Start by auditing your tools for replaceability. For each tool you rely on, ask: how long would it take me to switch to the next-best alternative, and what would I lose? A tool that would take an afternoon to replace is low risk. A tool that would take two weeks and significant data loss is high risk. Prioritize having alternatives ready for the high-risk tools.
For your highest-stakes workflows, consider the “one step removed” principle. Rather than storing your canonical data inside a tool, store it somewhere you control (a folder structure, a simple database, plain files) and use the tool to work with that data. The tool becomes a view and an editor, not the source of truth. This is more overhead, but for truly critical work it’s often worth it.
Finally, make the migration cost visible to yourself occasionally. Every year or so, do a light-touch exercise: could you actually export everything from your most critical tool and set up somewhere else? Not because you expect to, but because testing the assumption keeps you from being wrong about it at the worst possible moment.
Tools come and go. Good judgment about when to invest in a tool versus when to start building your exit stays useful forever.
What This Means
An acquisition announcement is not a crisis, but it is useful information. The companies that built the tools you rely on have changed their incentive structure. Their new owners are optimizing for different outcomes than the ones that made you choose the tool in the first place.
Your job is to read the acquisition type accurately, watch the early signals carefully, and maintain enough portability in your workflow that you can move when you need to without it being a disaster. The specific tool matters less than the underlying workflow it supports. Build around the latter, and you’ll find that switching is much less catastrophic than it sounds.
