Owning your tools again
Count the layers your working day runs on. Your judgement, your files, your history and context, the interface, the capability, the price. For most professionals, five of those six can change next Tuesday without anyone asking.
That is the whole argument. The rest of this note is about why "own everything" is not the answer, and what the achievable answer actually looks like.
The rental model, stated fairly
There was a period when software came on a disc, installed on your machine, and worked as long as you chose to use it. You paid once, the tool was yours, and Tuesday's update could not change what your workflow depended on because there was no Tuesday's update.
We are not arguing for that world back, and it is worth being explicit about why, because nostalgia is a bad foundation for a product decision.
The disc era was worse in ways people forget. Your work lived on one machine and died with it. Collaboration meant emailing a file and hoping. Security fixes arrived at the speed of postal mail. Version drift across a team was constant and invisible. And the capabilities involved in AI-assisted work simply do not fit on a local disc — not the models, not the index, not the compute. Anyone selling you full local ownership of this category of tool is selling you a much smaller tool.
So services won for real reasons. The problem is not that we rent. It is that the bill has line items nobody reads out at sign-up.
The three costs nobody itemises
Control. When your workflow runs entirely inside a closed platform, every change that platform makes is a change to your work. The interface that suited how you think gets redesigned by someone optimising a funnel you are not in. The integration your process depended on gets deprecated with ninety days' notice. Features you were promised arrive late or not at all. You can complain. You cannot refuse.
Portability. When your work, your history and your accumulated context live somewhere you do not control, leaving is expensive — in time, in migration effort, and in the loss of whatever the platform learned about how you work. That last one is the least discussed and the most binding. An export that hands you your documents but not the shape you had put them in is technically an export and practically a demolition. Portability that is possible but painful is not portability.
The negotiating position that follows. This is the one that compounds. When switching costs are high, the platform's interests and yours diverge structurally — not because anyone is acting badly, but because the pressure that would keep them aligned has been removed. You stay not because the tool is the best option but because leaving is harder than tolerating the way things are. Every subsequent decision the platform makes is taken in the knowledge that you will probably stay.
The two fixes we rejected
Both of the obvious answers here are wrong, and they are wrong in opposite directions.
Self-hosting everything. The purist answer: run it yourself, own the stack, revoke nobody's power over you because nobody has any. We rejected it because it does not survive contact with the work. It moves the whole burden of operations onto the professional, converts every capability improvement into a migration project, and — the part that actually kills it — it does not remove dependency, it relocates it. You still depend on model providers, on hardware, on whoever maintains the thing you self-host. What you have bought is not independence but a second job. For a small number of organisations that trade is correct. For a working analyst it is not.
Data export as the answer. The industry-standard answer: promise a download button and call the problem solved. We rejected this one too, more quietly, because we came close to shipping it as our whole story. An export button satisfies a compliance question, not a professional one. It hands you a folder. It does not hand you the ability to keep working. If the exported form is one nothing else can read, or one that drops the relationships that made the material useful, the button is a gesture. We would rather be judged on whether a leaving user can actually resume work somewhere else than on whether a file downloaded.
There is a third answer we hear often and reject faster: make switching costs high enough and the retention problem disappears. It works. It is also the mechanism the first half of this note describes. Choosing not to use it is the entire point.
What a healthier position actually looks like
Full ownership in the old sense is not available for this category of work. But the spectrum between "fully owned" and "fully rented" is wide, and where a tool sits on it is a design decision, not a fact of nature.
The markers are not complicated:
Your data should be exportable in a form you can actually use — meaning something another tool can read, with the structure intact, not a proprietary archive that satisfies a lawyer.
Your history and context should not be hostage. The thing the tool learned about your work is part of your work.
Core capabilities should not disappear because of a pricing restructure. The feature you built a process on should not become a tier.
And you should be able to run your workflow across surfaces — a web app today, a desktop application tomorrow, a terminal after that — without re-establishing who you are each time. Cross-surface friction is a retention mechanism disguised as an engineering limitation, and everyone in the industry knows it.
None of these are radical. They are what it looks like to treat professionals as people with their own interests rather than as an audience that has already paid.
What this costs us, and where we are not there yet
The honest version of a piece like this has to say what the position is costing, or it is just a values page.
Maintaining portability means not optimising for stickiness, and stickiness is the single most effective growth lever in software. Every decision to keep the exit clear is a decision to compete on the merits every month instead of on the sunk cost of leaving. That is a harder business and we are choosing it deliberately, not accidentally.
And we are not finished. Portability is easy to state and hard to finish, because the last twenty per cent of it is always the accumulated context rather than the documents — and the accumulated context is the part with no standard format to leave in. Anyone claiming this problem is fully solved, ourselves included, should be asked to demonstrate it rather than assert it.
The platform is designed to sit on the healthier end of the spectrum. It is not designed to sit at the end of it, because that end is not real.
What we would do differently
We would have written down the exit before we wrote down the product.
The order we worked in was: build something people want to use, then make sure they can leave. That sounds reasonable and it is backwards, because by the time you get to the second half you have already made a hundred small decisions that quietly assume nobody will. Formats, identifiers, how context is shaped, what is stored as a relationship rather than a value — each one is trivially changeable at the start and structurally expensive later. Portability is not a feature you add. It is a constraint you either designed under or you did not.
If we were starting again, the first document would be the one describing what a user takes with them when they go, and everything else would have to be compatible with it.
Own your workflow. It is worth the effort — and it is worth asking harder questions of anyone who tells you the effort is unnecessary.