ORCA exists to take weight off the people carrying too much of it. That is the whole point. Intelligence that compounds, confidence that is classified, judgement that stays human. A knowledge worker who can do the work they trained for, instead of the work in front of them.
So it stung when we caught ourselves doing the opposite.
The install that worked beautifully for machines
Yesterday we were hours from putting ORCA into the hands of our first customer. The automation was elegant. A single CLI walks the deployer through tenant selection, subscription pick, connector choice, licence verification, Bicep provisioning, Entra app registration, AKS cluster bring-up, Qdrant install, health checks. Every step idempotent. Every error actionable. Every resource tagged, traceable, and auditable. The kind of deployment tool a platform team would be proud to ship.
Then a human sat down to run it.
To get to the point where they could press play, they needed Node.js 20 on their PATH. And the Azure CLI. And PowerShell 7 for the Teams policy step. And Helm. And kubectl. And a safe working directory, because PowerShell on Windows defaults to system32 and silently breaks file writes. And a one-liner to install nvm, which their terminal client wrapped in angle brackets on copy, so it 404'd. And a second try through WSL, which copy-pasted modesource instead of nodesource. And a licence portal login, and a tarball download, and a manual extract, and an npm install --production.
By the time they had a clean shell, the cognitive load was through the roof. And they hadn't deployed anything yet.
The pattern we kept missing
We noticed something uncomfortable. ORCA reduces cognitive load for the knowledge worker — the clinician, the compliance officer, the finance lead. But we had never asked the same question about the person installing ORCA. The engineer doing the setup. The Ops Director running the migration. The Founder trying it out on a Saturday to see if their business should buy it.
Every complaint we heard was a small one. The curl URL got mangled. The nvm line didn't copy cleanly. My terminal ate the less-than sign. PowerShell doesn't know where my download went. Individually, none of those are problems we couldn't answer. Collectively, they were the exact condition ORCA exists to prevent: one person, too many open loops, no way to hold the whole thing in their head at once.
We had built the intelligence platform that reduces weight, on top of an install experience that added weight. The contradiction was complete, and we only saw it because a Founder tried to use it and told us it was too much.
The pivot
We stopped. We rebuilt the install surface as a single container image.
One docker run command. The container carries Node, az, kubectl, and helm inside it, pinned to versions we test against. It inherits the host's existing Azure login through a read-only volume mount. It refuses to start without a licence JWT bound to the tenant the deployer is authenticated against. It walks through the install exactly the way the old CLI did, because the old CLI is what it runs — we kept the elegant automation intact. What we removed was the path to reach it.
The engineer now runs:
docker run --rm -it \ -v ~/.azure:/root/.azure \ -e ORCA_LICENCE_KEY='...' \ ghcr.io/orcahqlimited/orca-installer:latest
Windows, macOS, Linux, WSL. It works the same way on all of them because the environment is the same on all of them. Upgrades are docker pull. Rollbacks are a pinned tag. The image is built by CI, signed at origin, and its provenance is published with every release.
What the work cost and what it bought
Four hours of founder time, late on a Saturday, to rewrite the install surface and harden the licence pipeline alongside it. In that window we also fixed a dormant issue — the licence service was regenerating its signing key on every restart, which would have invalidated every customer install in production the first time Azure scheduled a revision bounce. We only noticed because the install hardening forced us to verify the whole path end-to-end.
The fix bought us three things worth keeping:
- An install experience that respects the person running it. The container is the only thing they need to know about. Their mental model fits on an index card.
- A signing-key pipeline that will survive a restart. Persistent keys, signed licences bound to tenant, runtime enforcement in the gateway on every request, revocation that propagates within sixty seconds.
- A set of stable hostnames that sit in front of every service a customer install talks to. If we ever have to move a backend, it becomes a DNS edit at our edge — not a re-install for every customer in the field.
The lesson is the product
ORCA is built on the belief that the hardest thing about modern knowledge work is not capability. It is the number of half-finished tasks a person is carrying at once. The strategy document open in the wrong window. The compliance question that needs two sources and fourteen minutes. The meeting note nobody had time to write up. The cognitive load of holding it all in your head.
We kept saying that. We even proved it in the product. And then we built an install flow that committed the same crime we were promising to stop.
The uncomfortable truth is this: if the install experience is heavy, the promise isn't real. Not for the engineer. Not for the Founder looking at the shell. Not for the business paying the invoice. The lesson didn't come from a customer. It came from us, trying our own tool, feeling the weight, and admitting what we were feeling was exactly what we had told a customer they wouldn't have to feel any more.
Our first customer ships on the Docker build. The engineers will run a single command. They will not need to remember what Node version we tested against. They will not need to guess whether their terminal client is about to eat their curl URL. They will not need to hold anything in their head except the name of their customer and their licence key.
That is the version of ORCA we meant to ship. It took getting it wrong, in front of ourselves, to see where it needed to be.
If you are reading this and you build infrastructure that other humans install, this is the question worth asking every month: how much cognitive load do I make someone carry before my automation even starts? If the answer is "more than you'd like", the fix is not better docs. It is an environment that comes with its own hands.