A short read on the problem we're solving and the approach we're explicitly choosing — and the much more common approach we're explicitly refusing.
← Back to the dashboardThere is no master clock. There is no single calendar that all work flows through. There is no traffic cop deciding what happens next. Every actor — clients, artists, producers, studio leads, even physical hardware — pushes their state into one of several systems on their own schedule, in their own format, for their own reasons. The studio functions because humans hold the synthesis in their heads and re-derive it constantly.
That synthesis is the work Cr3ma exists to do.
This is not a project management problem. It is a distributed systems problem — and recognizing it as such is the difference between building yet another scheduling tool (the path most "studio management" software takes, and fails at) and building the thing that actually fits how a real post house operates.
Every system at RnP has its own writers, its own tempo, its own truth-claims:
mvThese never agree. They cannot agree. Forcing them to agree synchronously would break the studio, because it would require every actor to wait for every other actor to finish writing before doing anything. Real post houses can't operate that way — clients don't queue, deadlines don't wait, and Sean's coffee gets cold.
The studio survives because eventual consistency is good enough most of the time, and humans paper over the lag with verbal updates, hallway conversations, and gut feel. Cr3ma's job is to do that papering-over automatically, faster, and without losing the audit trail.
Different actors have authority over different facets of project state. No single actor has authority over all of it.
| Actor | Has authority over | Pushes state into |
|---|---|---|
| Client | Whether the work is acceptable; what notes to give; when to look | Frame.io (notes), Slack, email, in person |
| Artist | Whether the work is actually done, and what's possible in the next 4 hours | Slack, the timeline, Monday status flips, their head |
| Producer | Schedule, who's in what room, deadline negotiation | Timmy resource calendar, Slack, sometimes Monday |
| Natasha (Head of Production) | Pipeline state, deal funnel, billing readiness | Timmy (her primary tool — pipeline + calendar) |
| Sean & Crystal (Studio Leads) | Final call on conflicts, prioritization, client relationships | Monday board, Slack |
| The hardware itself | Whether a Resolve render is done, whether a drive is full, whether the color suite Mac is logged in | Logs, file system, sometimes nothing at all |
The hard truth: the producer and the artist often disagree about what state a project is in, and both are right within their authority. A project can be "Out for Review" in Monday (producer's view) and "still building the secondary on the wide and re-keying scene 14" in the colorist's Resolve session (artist's view) at the exact same moment, and neither is wrong. The system has to hold both.
Cr3ma is not a system of record. It does not own truth about anything. It is a synthesizer and a publisher:
The reads are pull-based and pollen-distributed (every system on its own poll interval). The writes are push-based and rate-limited. Nothing blocks anything else. No actor ever has to wait for Cr3ma to finish anything.
ACTORS (push state on their own clock)
┌────────┐ ┌─────────┐ ┌────────┐ ┌──────────┐ ┌──────────┐ ┌───────────┐
│ CLIENT │ │ ARTIST │ │PRODUCER│ │ NATASHA │ │ SEAN / │ │ HARDWARE │
│ │ │ │ │ │ │ Head of │ │ CRYSTAL │ │ (passive) │
└───┬────┘ └────┬────┘ └───┬────┘ └────┬─────┘ └─────┬────┘ └─────┬─────┘
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
┌────────┐ ┌─────────────────┐ ┌──────────────┐ ┌──────────┐ ┌──────────┐
│FRAME.io│ │ SLACK │ │ TIMMY.io │ │ MONDAY │ │ QNAP + │
└───┬────┘ └────────┬────────┘ └──────┬───────┘ └────┬─────┘ └────┬─────┘
│ │ │ │ │
│ AUTHORITATIVE SYSTEMS (each owns its own state) │
└───────┬───────┴─────────┬───────┴──────────────┴────────────┘
│ │
▼ ▼
┌──────────────────────────────────┐
│ CR3MA │
│ (synthesizer + publisher, │
│ pull-based, no central clock) │
└──────────────┬───────────────────┘
│
┌───────────────┼────────────────┬───────────────┐
▼ ▼ ▼ ▼
┌─────────┐ ┌───────────┐ ┌──────────────┐ ┌────────────┐
│ CRYSTAL │ │ SEAN'S │ │ SLACK PUSH │ │ MONDAY │
│ DASH │ │ SUPER │ │ (Block Kit │ │ ENRICHED │
│ PWA │ │ MONDAY │ │ buttons) │ │ COLUMNS │
└─────────┘ └───────────┘ └──────────────┘ └────────────┘
SURFACES (where humans actually look)
Most "studio management software" — and most consultants who try to fix studios — start from the opposite premise: if everyone would just use this one tool, all the problems would go away. They build the central traffic cop. Then they spend years failing to convince humans to actually use it, because the central traffic cop adds friction to every other actor's workflow to benefit one role (usually production management).
Not Natasha's. Not Sean's. Not the artists'. They'd lose the synthesis and have to do it in their heads again — which is exactly what they were doing before — but nothing they currently use would break.
That constraint is the test for every feature we add.
Sean's original ask, before any of this got ambitious.
This whole project started when Sean asked Eric a simple question: could you get Timmy to talk to Monday via an API call to build a simple information passing schema? That's a real scope. It's a legitimate scope. There's a version of Roast-n-Post's automation that stops there, and for some studios it would be enough. It's worth being honest about what that version looks like — because the gap between it and Cr3ma is the whole reason Cr3ma exists, and Cr3ma is overkill if you don't actually need the gap closed.
No AI. No synthesis. No friction detection. Just well-plumbed integrations:
It would work. It would solve the duplicate-entry problem for the fields that map cleanly. Sean's Monday board would catch up automatically when Natasha booked a project in Timmy. The studio would feel slightly smoother. It would take a couple of weeks to build, maybe a week of debugging, and then it would mostly just sit there and run.
The bespoke version is integration plumbing. It moves data around. It does not understand data. Specifically:
The bespoke version is the right answer if you want to spend two weeks and stop. It would solve maybe 40% of what RnP loses to friction. Cr3ma is the right answer if you want to keep building indefinitely against the same architectural foundation — adding sources, adding surfaces, adding intelligence — without ever rewriting the integration layer underneath. The investment cost is higher; the ceiling is much higher.
Both are valid choices. We chose the second because Sean and Crystal manage 125 projects across six pipeline stages with roughly twelve artists, and the friction state — the moments where a project is sitting waiting for a human to notice — is where the studio loses the most money. Friction detection is a synthesis problem, not a plumbing problem. So the answer needed to be a synthesizer.
If you're reading this and thinking I just want the integration: that's a one-week project, and Cr3ma's cr3ma/clients/ code already contains most of it. Pull out the Timmy → Monday flow, drop the dashboard, drop the Slack reader, drop the Frame.io poller, drop the synthesis tables, and you have the bespoke version sitting inside Cr3ma. The two are not mutually exclusive — they're the same shape at different scopes.