Challenge
TAMOSS is open source, so getting it running can be simple. You have all the access you need to clone the repo and have a store on your laptop in two commands. The hard part is everything after 'it works', everything from proving the store works with your workloads, on your infrastructure, with the tools your team already use in their production workflows.
Approach
We deploy a single-server TAMOSS on your chosen target, which can be one cloud, or one node. From there, we ingest a real workload that's representative of how you actually work. We then connect one or two of your existing tools over the TAMS API to fully validate the path end to end, from ingest to retrieval.
The crucial success criteria for our inital pilot is that you are in the position to fully operate TAMOSS. We exercise the operator's day two behaviour against your store. It corrects drift when a resource is changed, reports health through status conditions and Events, guards destructive deletes behind an explicit confirmation and runs runs the async lifecycle that keeps the store tidy. All parties leave the Pilot with evidence, documentation and operational knowledge to fully operate and maintain a TAMOSS store in your environment.
- 0
- Vendor lock-in
- v8.1
- API compatibility
- 3 weeks
- to validate
Two questions, answered with evidence
It works on your workflow
A representative real workload, ingested on your chosen target, with one or two of your existing tools reading from and writing to the store over the TAMS API. Proof on your content and your toolchain, not a generic sample.
It's operable, not just running
The operator's day-2 work, demonstrated against your store: drift correction, readiness through status conditions and Events, an admission guard on destructive deletes, and the async lifecycle workers. Observability wired to a collector so you can see it.
Three weeks, six phases
The same structured path as our other pilots, with the operability work landing in validation and handover.
Drawn tight, on purpose
A fixed price needs a fixed boundary. Here's exactly what the pilot covers - and what sits beyond it, in the engagements the pilot is designed to set up.
In scope
Single-server TAMOSS on one chosen target - one cloud or one node
One representative real workflow, ingested end to end
One of your two existing tools connected over the TAMS API
Operator day-2 demonstration: drift correction, status conditions & Events, destructive-delete guard, async workers
Observability hooked to a collector, or your Grafana where it's quick
Handover: the working deployment, an operations runbook, and a findings & evidence pack
Beyond the pilot
Multi-region or replicated production topology
Full toolchain integration beyond the one or two named tools
Production-scale data volumes or live content migration
Bring-your-own backends at scale (managed Postgres, S3 estate, OIDC)
These become the ProServe or managed-service engagement - see below
The questions worth meeting head-on
Cary Haine, Head of Media Infrastructure
TAMOSS is open source, we could deploy it ourselves. Why pay for a pilot?
LiveWyer
You absolutely can - the self-serve route is free and supported
What you're buying here is the confidence in your workflow and infrastructure, fast, plus the day-2 operability work proven rather than discovered later. You keep the deployment and the runbook either way; the pilot just gets you there in three weeks with evidence in hand.
Beryl Judingham, Platform Lead
You say 'operate', but a pilot is time-boxed. What does operating actually mean inside a fixed engagement?
LiveWyer
We demonstrate operability; we don't take on ongoing operations
Inside the pilot we prove the operator's day-2 behaviour against your store and document it in a runbook. Ongoing operation - SLAs, on-call, managed running - is a separate engagement the pilot is designed to set up, so the fixed scope stays fixed.
Sukayo Baka, Director of Technology
If the pilot goes well, what happens next?
LiveWyer
You choose the depth of the next step
Build on the pilot with ProServe - fixed-price or T&M - to take it to a production-shaped, multi-server deployment, or move to a managed model where we operate it with you. There's no obligation to continue: the pilot stands on its own
Cary Haine, Head of Media Infrastructure
Are we locked into the one cloud we pick for the pilot?
LiveWyer
No - that's rather the point of TAMOSS
The pilot targets one cloud or node to keep scope tight, but the same operator-driven product runs on EKS, GKE, AKS or your own hardware. What you validate on the pilot target is what you run anywhere else, with backends and auth pluggable via the same declarative interface.