The unglamorous half of owning a platform: keeping it current, keeping it correct, and proving both on the running system rather than in a report.
This is the fee that answers "what am I paying for once it works". A deployed platform is not a finished object. Providers change their model catalogues, policies need new versions, people join and leave, costs move, and every change has to be rolled to a live system without breaking the controls that make it defensible. That work is what $500 a month buys, and nothing else is bundled into it.
Six specific things, rather than "monitoring and support". Everything below is work somebody does, on your deployment, and writes down afterwards.
Every deploy is from a pinned tag on the mainline. The roll is one deployment at a time, confirmed before each one, with your deployment able to hold at a version and say why. There are no automatic fleet-wide updates.
What is actually running is compared against what the code says should be running, with two tools rather than one, so a difference one comparison misses is caught by the other. Differences get reconciled before anything is applied, not after.
After a deploy, scripts exercise the real deployment over HTTPS and each one must be refused. They exist because a passing unit suite proves what the code intends, and only a real request proves what the deployment does.
Providers add, retire and re-route models constantly. The catalogue is regenerated from the provider's live list and reclassified by where inference actually runs, so your allowlist and your residency claim stay true. Nobody retypes a model name into copy.
People join, change jobs and leave. Grants are runtime-editable by your administrator without a redeploy; where a change touches the allowlist, the policy, the tier or residency it is a release, and we cut it. Quota changes sit here too.
Budget alarms on your cloud spend, a look at what usage is doing to the bill, and a dated operations journal recording what was changed, when, and why. The journal is the record you hand a reviewer who asks what happened in April.
Roughly 2,700 automated cases run before a release is tagged, including ones that fail the build if a governance deny is weakened. That is necessary and it is not sufficient. These scripts go at the deployment itself, over the public protocol, and try to get through.
| Work | When | What you see |
|---|---|---|
| Release rolled to your deployment | When a release is cut and you agree to take it | A confirmation before, a journal entry after, and the running version visible on the health endpoints |
| Drift and diff check | Before any change is applied | The differences, and what we intend to do about each one |
| Acceptance scripts | After every deploy | The result of all five checks, on your deployment, dated |
| Model catalogue refresh | As providers change their catalogue | A regenerated catalogue, with each model reclassified by where inference runs |
| Access, role and quota changes | When you ask | The change, plus the audit record the product writes itself |
| Cost watch | Ongoing, against budget alarms on your account | A heads-up when spend moves, and the reason where we can find one |
| Operations journal | Written as work happens | A dated record of what changed and why, available to your reviewer |
Every row is work performed by a person and recorded afterwards, which is why each one arrives with a reason attached rather than as an automated notification.
The fee keeps what exists correct and current. Two things sit outside it, and both are better named here than discovered in month three.
Building something that did not exist before is scoped per deliverable: a named outcome, acceptance criteria written first, a fixed price for that deliverable. The monthly fee keeps what exists correct and current. It does not quietly absorb a new module, a new integration or a new workflow, because that is how a monthly fee turns into an argument.
No queue, no account manager, no first-line tier to get past, and a change you ask for is made by someone who can read the code that implements it. There is no published response-time or uptime commitment attached to it. If round-the-clock cover is a hard requirement for your organization, say so in the assessment: it is a reason to shape the engagement differently, or to choose somebody else.
There is no term and no notice penalty. Cancelling ends the service, not your access to the thing you paid to have built, because the two live in different places: one is a monthly relationship with us, the other is deployed inside a cloud account in your name.
You lose us, not the platform.The whole cancellation policy
Catalogue upkeep as providers change things, any release you choose to take, drift checks, the acceptance run after a deploy, cost watch, and the journal. A quiet month is a cheap month for us and we would rather that than invent work. If it stays quiet for long enough that you question the fee, cancel it and call us when you need us; the platform will still be there.
Samuel Hebeisen, the founder and the person who built the platform. That is the whole escalation path, which is both the strength and the limit of a small senior practice.
It depends on the posture you chose. At the entry tier no cross-account role for us exists at all, so operations work happens with your involvement. On the hardened tiers there is a scoped, session-capped management role. Either way the access is a recorded part of your posture, visible to you on the plan page inside the product.
Yes. A deployment can hold at a version with a declared reason, and the fleet roll skips it. Holding deliberately beats taking an update because a schedule said so. The one rule is that a hold is declared: the reason is written down.
The operations fee is $500 a month regardless of how many people use the deployment, because it is not a seat price. What grows with usage is your cloud bill, which your provider sends you directly. Capability work is separate and quoted per deliverable. See pricing and compute costs.
The assessment is where we work out whether you want us running this, or whether your own team should.