We have written elsewhere about which local tool replaced which paid one, the clean category-by-category mapping. This is the other half of that story, the half the mapping leaves out: the move itself. How we decided to go, the order we did it in, the weeks we ran both systems side by side, the things we were genuinely nervous about, and what changed in the actual work once the subscriptions were gone. This is a story about a decision unfolding over time, not a table.
Why we decided to move at all
It did not start as a principled stand. It started as a feeling that crept up over a few months: a low background unease about how much of the studio’s daily work passed through systems we did not own. Every draft, every snippet of code, every interview transcript went somewhere else to be processed, on someone else’s terms, billed by the month. None of it was a crisis. It was just an accumulation, and one day the accumulation was loud enough to act on.
There were three threads to the unease, and they tightened together. One was privacy: client code and unreleased documentary audio are not things we love sending out of the building, even to a trusted vendor. One was cost, the quiet kind, where a handful of separate subscriptions add up to a monthly number you stopped looking at. And one was fragility: the work stopped when the connection did, and a studio that cannot work on a plane or during an outage is more brittle than we wanted to be. We will not put a figure on the savings here, because it depends entirely on which subscriptions you carried. [CONFIRM: the studio’s monthly subscription spend before the move].
The decision, when it came, was not “rip everything out this week.” It was quieter than that: we would move, deliberately, one job at a time, and we would not break the studio doing it.
The order we migrated in
The order mattered more than anything, and we did not pick it at random. We moved from least scary to most scary, so that each success bought us confidence for the next.
We started with the engine, before any tool. Installing Ollama and pulling one model was the foundation, and we would not touch a single tool until that engine answered a question with the Wi-Fi off. That first offline answer is a strange and convincing moment, and it set the tone for everything after. With the engine proven, every later step became “point a tool at the thing we already have” rather than “build something new.”
Then we moved the lowest-stakes job first: everyday chat and drafting. If a local chat tool produced a worse email draft, the cost of that was a slightly worse email, which is nothing. Moving the harmless job first let us learn the rhythm of local tools where mistakes did not matter.
Coding came next, and we approached it carefully because code is the thing we least wanted leaving the building, which made it both the most valuable swap and the most nerve-wracking. We pointed OpenCode at the local model and lived inside it. Transcription for documentary work and document Q&A came after that, in their own time. By the end we had moved every AI job that mattered, but we moved them in a sequence that always kept the studio running.
The weeks we ran both at once
Here is the part the mapping never mentions, and the part that made the whole move survivable: for a stretch, we ran both systems in parallel.
We did not cancel a subscription the day we installed its local replacement. That would have been a bet, and we do not bet the studio’s daily work. Instead, for each job, we ran the local tool as the default and kept the paid one open beside it as a safety net. When the local chat tool drafted something, we used it. When we were unsure, the old tool was one tab away to check against. This parallel period did two things. It let us catch the places where the local version actually fell short, instead of guessing at them. And it let trust build at its own pace, which for some jobs was a day and for others was a couple of weeks.
The rule we used to end each parallel run was simple: we cancelled a subscription only after we had gone a full normal week without reaching for it. Not after it felt good in a demo. After a real week of real work where we never once opened the paid tool. When that week passed, the subscription came off the bill, and not a day before. [CONFIRM: how long the full parallel period lasted across all tools].
What we worried about
It would be dishonest to pretend this felt smooth the whole way. We worried about real things.
We worried the local models would be too weak for serious work, and on the hardest coding problems that worry turned out to be partly true. The model is the ceiling, and on a genuinely gnarly task a frontier cloud model is still ahead. We made peace with this by keeping a cloud option for that single class of problem and using it on purpose, not by reflex.
We worried about maintenance, that we were trading a polished hosted experience for a pile of things we now had to keep running ourselves. That worry was fair. The engine, the tools, the updates: they are ours now. The honest truth is that it has been far less work than we feared, but it is not zero, and anyone making this move should expect to own the upkeep.
And we worried, quietly, that this was a vanity project, that we were doing it to prove a point rather than to do the work better. The parallel period answered that one. If the local tools had been worse at the actual jobs, we would have kept the subscriptions and said so. They were not, so we did not.
What actually changed in the work after
The strangest thing about the move is how little drama there was on the other side of it. We expected a new way of working. What we got was mostly the old way of working with three differences.
The first difference is that nothing leaves the building anymore, and that turned from an abstract privacy argument into a felt calm. You stop performing a small risk calculation every time you paste client code into a tool. The second is that the monthly bill stopped growing as we added tools, because adding a tool now means pointing it at an engine we already run, not signing up for another service. The third is the one we did not anticipate: the work kept going during an outage, on a flight, in a cabin with no signal, and that resilience changed how it felt to depend on these tools at all.
What did not change is just as important. The actual coding, drafting, transcribing, and document work feels the same on a normal day. We did not get slower. We did not adopt a worse process. For the great majority of the work, the move was invisible in the output and visible only in the things around it: the bill, the privacy, the resilience.
The takeaway
If you are thinking about this move, the lesson of our case study is not which tools to pick. It is how to move: start with the engine, migrate from harmless to high-stakes, run both systems in parallel until a full quiet week earns the cancellation, and keep a cloud option for the few problems that genuinely need it. We did not flip a switch. We walked across, one job at a time, with a safety net the whole way, and we only let go of each rope once we were sure we no longer needed it.
That is the transition, start to finish. Curious about these things. You should be too.
Harness your curiosity.
— Stridenote · № 010