Figma, Adobe, and the Tooling Resilience Question

It has been almost eight months since Adobe announced its intent to acquire Figma for $20 billion, and the deal is still where it was at the new year: under regulatory review on multiple continents, with the DOJ and European authorities taking long, public looks. Meanwhile every design team I know is running the same background process: nervously refreshing the news, half-drafting contingency plans, and asking each other at meetups what happens to pricing, to FigJam, to the plugin ecosystem, to the features that exist specifically because Figma was competing with Adobe.

I have no inside information and neither does anyone else posting takes. So instead of predicting the outcome, let me offer the framing we have adopted at Slipway, because it is useful regardless of what regulators decide.

The real exposure is process, not software

Here is the audit question that matters: if your primary design tool changed materially in twelve months, in price, in performance, in direction, what would you actually lose? For most teams the honest answer is not "our files." It is "our entire way of working," because the process has fused with the tool. Component conventions that only make sense in Figma's model. Handoff rituals built on specific plugins. Documentation living in comments. Design tokens that exist only as styles in one proprietary file format.

That fusion happened for good reasons; Figma earned it by being genuinely better. But convenience quietly became dependency, and the acquisition review is simply the moment everyone noticed.

What we changed, concretely

We did not switch tools, and we are not planning to. We made the process portable while staying happily where we are:

• Tokens live outside the design file. Colors, type, spacing, and motion values are maintained in a plain JSON source of truth that generates both our Figma styles and our code variables. The design tool consumes the system; it does not own it. This was worth doing anyway, and Grace's team had been asking for it for a year.
• Decisions are documented in documents. The reasoning behind a system's architecture lives in written form in the project repo, not in a thread of canvas comments that will never survive an export.
• Component conventions are written down tool-neutrally. Naming, composition rules, and variant logic are described in language any competent tool could implement. The Figma library is an expression of the system, not its definition.
• Regular exports are boring and scheduled. Not because we expect a catastrophe, but because backup hygiene should never depend on trusting any vendor's roadmap, and that was true before September.

None of this took longer than a sprint, and every piece of it improved daily work immediately. Resilience that costs nothing until the disaster is usually resilience you will not maintain; the trick is choosing the version that pays rent in normal times.

A word in defense of not panicking

Some teams have responded to the uncertainty by tool-hopping preemptively, and I want to gently argue against it. Switching tools costs a team months of muscle memory and library rebuilding, in exchange for insurance against an outcome that remains genuinely unknown: the deal may close, may be blocked, or may close with conditions. Paying a certain cost to hedge an uncertain one is only smart when the certain cost is small. A full migration is not small.

The deeper lesson our industry keeps relearning, from font licensing changes to plugin platforms sunsetting, is that tools are rented and craft is owned. Typography knowledge survived the death of every tool I learned it in. Systems thinking transfers. The teams that will be fine in every version of the Figma future are the ones whose expertise was never located in the software to begin with. Make your process portable, keep your judgment sharp, and let the regulators take their time.