One deployment per enterprise customer.

Winsen One comes in three arrangements, and the honest version of this essay starts by separating them. The managed tier is one shared, multi-tenant deployment: a small team hires an AI employee for a monthly fee with a usage limit, on infrastructure we run for everyone on that tier, and we say so plainly. The two enterprise arrangements are different animals. Each enterprise customer gets a dedicated, isolated unit, running at company.winsen.one or inside the customer's own infrastructure, with its own database. One customer, one unit. Nothing shared. This is an unfashionable architecture for a software startup, and we want to explain why we think it is the only honest one for the buyers those arrangements serve.

Multi-tenancy is the vendor's architecture

Multi-tenant SaaS is a genuinely great invention, for the vendor. One deployment to run, one version to support, margins that improve with every signup, telemetry aggregated across everyone. The buyer's side of that trade is a set of promises: your rows are separated from other companies' rows by access-control logic, your traffic shares infrastructure with strangers, and a bad day in the shared system is everyone's bad day at once. For a marketing tool, the trade is fine. It is fine for our own managed tier too, where a small team is trying its first AI employee and the stakes fit the arrangement. For the documents inside a credit file review or a quality records process, it is a paragraph of reassurance where a structural answer should be, which is why the enterprise arrangements refuse the trade entirely.

What a dedicated unit means, concretely

• →Your own database. Not a shared cluster with row-level security. A database with your name on it, whose backups, retention, and deletion are yours to govern. Your data lives there, is never mixed with another customer's, and leaves with you when you leave.
• →Model access provisioned for your unit. Inference is provisioned and governed as part of the deployment, configured for your unit alone, never pooled with another customer's traffic.
• →Isolated compute. Your documents are never processed on infrastructure another customer's workload can touch.
• →Your subdomain or your infrastructure. company.winsen.one when the unit runs on our infrastructure, your environment when the arrangement puts it inside yours. Either way it runs on Platos, our runtime, operated by us. Platos is open source, so you can read exactly what is running in your building, and we operate it so you never have to.
• →Upgrades as change control. Your unit moves versions on a schedule you can see and gate, not whenever the vendor deploys on a Tuesday.

Regulated buyers force this honesty

Run a security review with a bank, a manufacturer under quality regulation, or a logistics operator handling customer-contracted freight data, and the questions are always the same. Where is our data, physically? Whose workloads run beside it? Which model providers receive it, and under what agreement? What leaves with us when we leave? Multi-tenant vendors answer these with essays. A single-tenant unit answers most of them in one sentence each, and the sentence is checkable.

The honest answer to where is our data is a database with your name on it, not an essay about row-level security.

The same logic holds on the bad day. A defect, a breach, or a bad migration in a shared system is everyone's incident at once. In a per-customer unit, the failure domain is one company wide. That does not make incidents impossible. It makes their scope honest, and it makes the conversation after one honest too.

What this costs us, honestly

We are not pretending this is free. A fleet of units is more operational surface than one big deployment: more upgrades to run, more monitoring to watch, worse economics at small scale, slower experiments because changes roll out unit by unit. We spend real engineering on making the fleet operable from one control plane, provisioning, upgrading, and monitoring units the same way, so a small team can run many of them without heroics. It is also why the enterprise arrangements begin as engagements, with our engineers deployed against your processes, rather than as a signup form. We accept the overhead because for this buyer the deployment model is not an implementation detail behind the product. It is part of what they are buying.

There is a version of this company that runs every customer, every workload, in one big shared database and grows faster. We think that version never earns the workloads that matter in financial services, manufacturing, and logistics, because the architecture itself would be making a promise the buyer has no way to verify. The shared tier exists for the teams whose stakes fit it, and it is labeled as exactly what it is. For the buyers who need more, one deployment per customer is slower to operate and easier to trust. We know which side of that trade we want to be on.