We could have taken the simplest route: call models from an external provider and consider it done. But we chose another path β we run our own models on home infrastructure. This isnβt just a technical choice; it is a conviction about what a trustworthy intelligent system should stand on.
One thing to make clear from the start: what follows applies to on-premise deployment, where the model and the data both stay inside the customerβs environment. In cloud deployments or showcase versions, external providers may still be used. This is not a blanket promise for every form of deployment β it is the option that puts control and isolation in the organisationβs hands.
Independence
The first reason is independence. When the core intelligence of a product is tied to an external provider, the productβs fate is tied to it too: its pricing, its availability, its decisions about what is and isnβt allowed. We believe a serious system shouldnβt be that dependent. Running our own models means the productβs path is in our own hands, not in the hands of someone whose decisions we canβt control.
Keeping data at home
The second reason is data. When data is sent to an external service for processing, it leaves your boundary of control. For many uses β especially those dealing with sensitive information β this is simply not acceptable. Running models on home infrastructure means data stays home: under the roof where it should be, without having to go somewhere it shouldnβt for processing.
Local language and context
The third reason is local fit. Models cultivated for the Persian language and context perform better in our usersβ real work. Building the ability to run these models on our own infrastructure lets us invest in exactly what matters most to our users, rather than settling for what a general provider offers.
A conviction, not a claim about numbers
We want to be honest: this is a strategic decision, not a claim about numbers. Weβre not saying this route is always cheaper or faster; weβre saying we value independence, keeping data at home, and long-term durability, and weβre willing to pay for it. This is a choice based on priorities, and we state those priorities clearly.
The alternatives, and where ours loses
Ours is not the only defensible choice, and it isnβt the right one for everyone. The honest field looks like this: a cloud-API-only setup is the fastest to stand up and offloads all the operational burden, at the price of sending data across your boundary and tying your fate to a provider. Multi-tenant SaaS is cheaper and simpler still, but your data shares a platform with everyone elseβs. A fully air-gapped deployment maximises isolation but gives up the convenience of any managed service and slows every update to a manual crawl. An ecosystem-locked stack is smooth as long as you stay inside one vendorβs walls β and costly to leave. Our position β on-premise by default, plus an isolated, Felesh-managed cloud β sits deliberately toward the control end of that spectrum.
And it loses something real to get there. Running your own infrastructure costs more up front than a metered API and carries an ongoing operational burden β hardware, serving, upgrades β that a cloud provider would otherwise absorb. It is slower to spin up, and slower to adopt the newest frontier model the day it ships, because we have to bring it in-house rather than flip a flag. For a small team, a low-sensitivity workload, or a quick experiment, a cloud API is very often the better trade. We choose the control end because durability and isolation matter most for the systems we build β not because the other options are wrong.
Putting it together
Running our own models on home infrastructure is a long-term entrenchment: independence from othersβ decisions, keeping data under our own control, and investing in local fit. We believe an intelligent system meant to stay trustworthy for years should stand on a foundation it controls itself. This is our decision, and this is its reasoning.