A small team building infrastructure for video.

Video infrastructure looks finished. It isn't.

From the outside, the video stack feels solved: AWS Elemental, Bitmovin, Mux, FFmpeg in a Lambda. From the inside of any team running real broadcast or OTT volume, the picture is different. There's a queue manager written by someone who left two years ago. A retry path that nobody fully trusts. A spreadsheet of which preset works on which network. The shape of the work is a directed graph with retries, audit, and tenancy — but the tools sold to do it are either rentable encoder-minutes (no orchestration) or end-to-end portals (no control).

The opinionated middle is empty.

On one end, you can rent FFmpeg-as-a-service and write your own DAG, queues, retries, audit, and multi-tenant isolation. On the other end, you hand the entire pipeline to a managed portal that owns your storage, your presets, and increasingly your customer relationship. There is real demand for the middle: a control plane you can run that knows about jobs, queues, retries, and tenant isolation as first-class concerns — without swallowing the rest of your stack. That is the gap we are building into.

Broadcast-grade is a posture, not a feature list.

The teams we are building for ship live news, sports, OTT libraries, and archives that mean something to viewers and to legal. They don't need another encoder; they need an orchestration layer that fails predictably, audits everything, and survives the worst day of the quarter. Our north star is the on-call engineer at 3am — the one whose pipeline must answer the phone.

Founder — engineering and product

MpegFlow is founder-led. The person writing the architecture is the same person on the design-partner intro call, the same person debugging your first encode, and the same person answering the security questionnaire. Pre-GA, that is by design: it keeps feedback loops short and the product honest.

Twelve years building video and media infrastructure before MpegFlow — most recently as principal engineer on a multi-tenant transcoder platform that handled broadcast-grade VOD ladders, archive migration at petabyte scale, and the kind of multi-region failover where the wrong answer ends up on the front page. Earlier: encoder pool engineering on the OTT side of a major streamer, and before that, broadcast ingest and packaging at a regional network where the only SLA that mattered was "the show goes on."

Background centers on FFmpeg internals at production scale, distributed encoder pools on Kubernetes, broadcast and OTT workflow orchestration, codec packaging (HLS, DASH, CMAF), and the operational reality of multi-tenant pipelines that have to answer the phone at 3am. Comfortable in Rust and Go for control-plane work; comfortable enough in C to read libavcodec when the docs run out.

MpegFlow exists because the same gap kept showing up across teams: a perfectly good encoder vendor on one side, an over-grown spreadsheet of orchestration glue on the other, and the reliability of the whole pipeline pinned to whoever wrote the queue manager. That opinionated middle is what we are building into. Working with me directly during the design-partner program means same-day turnaround on real bugs, a written architecture review of your current pipeline before anything ships, and public reasoning on every non-trivial call — the engineering blog is mine.

Public work and writing linked from the engineering blog. Reachable directly via the contact form; response inside one business day.

Hiring posture

We are not hiring engineers ahead of revenue. The discipline of staying small until the product earns its next hire is part of the trust we are asking design partners to extend. When that changes, the open roles will appear here, with role descriptions written by the person you would actually report to.

Advisors and operators

We work with a short list of broadcast and OTT operators who pressure-test architecture decisions before they ship. They are not on the cap table for vanity; they are on it because the product is sharper for their input. Names go up here when they go up — not before — and only with explicit consent.

Build for the on-call engineer.

If a feature does not survive 3am — clear logs, predictable failures, no clever hidden state — it does not ship. The pager is the user.

Treat the data plane as a contract.

Customer storage stays in customer storage. Workers receive presigned URLs and emit hashes. The control plane never sees the bytes. This is a load-bearing decision, not a marketing line.

Boring tools, hard guarantees.

PostgreSQL, Rust, Kubernetes, FFmpeg. Nothing here is novel; the leverage is in how the pieces are wired together. Operators trust boring infrastructure faster than they trust new infrastructure.

Public reasoning.

The architecture choices have public write-ups on the architectures page and the engineering blog. If we cannot explain why a decision is right, we have not made it.