The Tool Is Replaceable. The Process Isn't.
Last week I shared my thoughts on the Airtable acquisition. This week, a natural conversation has emerged that's less about Airtable specifically and more about something bigger: what happens when a tool you've built your business around changes in ways you didn't choose?
It's a question worth sitting with, because Airtable won't be the last.
Your project management tool, your CRM, your forms app, your scheduling layer; some of those will get acquired, restructured, or repriced in the next few years by owners with different priorities than the founders who originally built them. You can't predict which ones, but you can build in a way that insulates you from those changes.
The right question to ask
When news like this breaks, most people immediately jump to: should I stay or should I go?
That's the wrong question, at least right out of the gate.
The better question for you right now is: what happens the next four times this occurs? Because it will. And when it does, will you be reading that email as information, or as an emergency?
Many teams have this backwards. They pick tools and then let the tool define the process. Then when ownership changes, they discover the process was never really theirs.
Two buckets to get clear on
When you strip away the tool name, when you forget for a moment that it's called Airtable or HubSpot or ClickUp, what you're actually left with is two things:
Your data. Everything you're storing. Leads, clients, projects, payments, content, to-dos; whatever lives in the tool. Get clear on what all of it is, what it represents, and how it's organized. If you had to move it tomorrow, would you know exactly what you have?
How you interact with it. This means more than just who uses the tool day to day. It also means your automations: the Zaps or workflows that move data from one place to another. It means the interfaces and dashboards your team uses to do their work. It means the reports leadership looks at every week. All of that is built on top of your data. If the tool changes, all of that is at risk too.
Getting clear on your data and how you interact with it puts you in a much stronger position than many teams are in right now.
The Five W's of your processes
My journalism background is showing here, but bear with me: if you approach process documentation with a who, what, when, where, and why mentality, you'll capture everything that matters.
Who does this process involve, and who does it affect?
What actually happens?
When does it happen?
Where does it fit in the larger scope of your operations?
Why does it exist?
If you can answer all five of those questions for each of your core processes and write it down somewhere outside the tool that runs it, you own that process. The tool becomes replaceable; the process isn't.
Where you store that documentation matters too. A lot of people use Notion, which is fine (though yes, that's also a tool that could also theoretically change). A shared Google Doc is a simpler bet for most small teams. The specific destination matters less than the principle: your process documentation should live somewhere separate from the tool that executes it.
Know what's load-bearing
Not every tool in your stack carries the same weight. Some are essential to how your business actually runs. Others are convenient but replaceable. Knowing the difference is important, and it's another reason to keep an internal software catalog.
If you read my newsletter on tech stack hygiene back in July, this is where that work pays off. When you have a clear list of every tool you're using, what it does, and what value you're getting from it, you can quickly identify which ones your business genuinely depends on and which ones you could swap out without missing a beat. That clarity is what lets you respond to news like the Airtable acquisition calmly instead of reactively.
What to actually do
This isn't a code red. You don't need to drop everything this week and migrate off Airtable immediately, but there are a few things worth doing sooner rather than later:
Get clear on your two buckets: your data and how you interact with it
Document your core processes using the who, what, when, where, and why framework
Make sure that documentation lives outside the tools that run those processes
Review your software catalog and identify which tools are load-bearing versus convenient
Set a regular cadence for keeping your documentation up to date, and decide who owns that
The teams that navigate tool changes well aren't the ones who always picked the right tools from day one. They're the ones who stayed proactive about their own operational clarity, who knew what they had, how it worked, and why it mattered before they ever needed to move.
The best time to do that work is before something forces you to.
Before we wrap
Are your core processes documented somewhere outside the tools that run them? If not, that's your starting point.
And as always, if you want help auditing your stack and getting your processes documented in a way that's actually useful, that's exactly what I do. Book a free discovery call at processpowerup.co/schedule-a-call.
See you next week!
— Andrew