Marain

Approach

Public, then hybrid, then private, one workload at a time.

This page is here as evidence rather than as a pitch. It is the set of decisions I make when I build, and I make them on my own systems first, which is why I can tell you what each one costs in practice.

The path is drawn below with its five forces as switches. Name a workload and flip them, and watch where it lands.

The deployment path

Where a model runs is a trajectory, and you revisit it.

You do not have to choose perfectly on day one. Start public to ship, move a workload private only once it has earned the extra effort, and keep the decision reversible in both directions.

What moves a workload along the curveFive forces, weighed per workload.

a workload
  1. Public

    Start here

    Frontier APIs. Fastest to value, lowest upfront cost, best raw capability. Right for proving the use case and for any non-sensitive workload. Most work should begin here, because shipping settles arguments that theorizing cannot.

  2. Hybrid

    Where most mature organizations land

    As usage grows, some workloads develop reasons to move: sensitivity, cost, latency, control. A gateway classifies and routes, so sensitive or high-volume work runs private and everything else stays on the frontier. Providers stay abstracted, so switching models is a configuration change rather than a rebuild.

  3. Private

    For the workloads that warrant it

    Self-hosted, data-sovereign deployment for the highest-stakes slice: regulated data, sustained volume, strict latency or control. Rarely everything, and deliberately the part that earns the added effort.

  1. iData sensitivity and regulation
  2. iiQuality bar
  3. iiiCost at scale
  4. ivLatency and availability
  5. vControl and lock-in

Flip each force and the marker moves.

Public where it makes sense, private where it matters. That is a technical position, arrived at one workload at a time.

The evidence

I run this on myself before I recommend it to you.

Marain’s own operations run on the path above. Frontier models handle drafting and classification. A router sends anything carrying personal data to models on hardware I own, at home, over a private network. A public search index runs on a small server in Germany. Here is what that costs and how often it breaks.

34
automations running the practice itself
0.47%
execution failure rate across them

7 failures in 1,498 executions, drawn one tick each — the fortnight to 12 September 2026

2
domains under one public semantic search index
11,278
people in the relationship graph behind the pipeline

The free tools on this site are the same architecture in miniature: scoring runs in your browser, nothing is stored, and the one tool that does run on my side says so on the page.

Try the tools →

The hybrid gateway

One boundary that classifies, redacts and routes.

Sensitive data is classified and kept home, non-sensitive work goes to the frontier, personal data is redacted at the boundary, and every call is logged. Because the providers sit behind an abstraction, changing model is a line of configuration.

Models, prices and regulations all move. Someone has to keep that routing correct afterward, and if it is going to be your team, that is a thing I teach rather than a thing I keep.

the boundarya drafta ticket with a person's data in itredacteda classificationfrontierhardware I ownevery call logged

Bring me a workload and I will tell you where it belongs.

Thirty minutes is usually enough to place it, and to say whether it is worth building at all.