Keeping your work portable

The quiet accumulation

After a year of using one product, a surprising amount of your working life lives inside it: custom instructions, a dozen projects with their own context, saved conversations you refer back to, uploaded reference files, memory it has built about you, and a set of habits shaped around its particular features.

None of that was a decision. It accumulated, and it is what makes switching feel impossible even when your own twelve prompts say a competitor is better.

The three things worth keeping outside

Your instructions. The saved prompts and project contexts from the previous lesson, in a plain text file. This is the most valuable and the easiest.

Your reference material. The documents you keep uploading. Keep the originals in your own folder; a copy inside a product is a copy, not the original.

Your decisions and findings. The twelve-prompt file, the decision record, the notes about which tool does what. A separate folder, in plain text, backed up like anything else.

Three files and a folder. Twenty minutes to set up, and it converts a switch from a fortnight of rebuilding into an afternoon of pasting.

Testing the exit before you need it

Before committing to any product, find the export function and use it once. Two questions:

Does an export exist at all? Most major products offer one, often under Settings, Data controls, Export. Some produce a download link by email within a day.

What is actually in it? This is where they differ. A good export contains your conversations in a readable format. A poor one contains conversations without the attachments, or without project contexts, or as a data file with no way to read it.

Do this in the first week, when leaving is still easy. Doing it later, in the week you have decided to leave, is when people discover the export is a JSON file with the uploads missing.

What lock-in actually looks like

It is rarely a contract. It is four softer things.

Habits. Keyboard shortcuts, the shape of the interface, knowing how it behaves. Real, and it fades in about a fortnight.

Integrations. Connectors into your mail, drive and repository, each of which took a decision and a permission grant. Rebuilding them is an afternoon.

Accumulated context. Memory and history that make the tool feel like it knows you. This is the one that does not transfer, and it is worth being clear-eyed about: much of it is convenience rather than capability.

Sunk cost. An annual plan with seven months left. This is the only one that is actually money, and it is a reason to be careful about annual plans in a field that moves this fast.

Memory, and the part that does not transfer

The one non-portable thing is what a product has learned about you across months of conversations. There is no export that captures it usefully, and no way to load it into a competitor.

The honest response is to demote it. Open the memory page and read what is there; most of what matters is a handful of durable facts: what you do, who you write for, your standards, your language. Write those into your own instruction file. What remains is the incidental residue of old conversations, and losing it costs less than it feels like it will, which is worth knowing before it becomes the reason you stay somewhere.

The portable core

There is a version of your setup that survives any product disappearing tomorrow:

• A folder with your instructions, your reference documents and your twelve prompts.
• An API key or two, usable from any front-end.
• A local model installed.
• A free open front-end that accepts any provider.

Someone with that arrangement is never stuck. The product they use daily might still be a commercial one, chosen because it is better, and the point is that it is a choice they keep making rather than one they made once and can no longer revisit.

That is what portability buys. Not independence for its own sake, but the ability to act on your own six-month review instead of reading it and doing nothing.