From briefed to approved, without leaving the app

1 — The brief goes in first

An Owner or Admin creates a task and attaches the reference files: the brief, the brand guide, the raw footage. These are the brief, and they stay the brief — a Contributor can read and download them but cannot replace them.

That separation is the decision the whole product hangs off. When reference material and finished work sit in the same folder, someone eventually overwrites the wrong one.

2 — One person owns the task

Tasks are assigned to a single contributor. There is no shared pile — if a task is yours it says so, and if it is not, you are not wondering whether to start.

3 — The work is uploaded, however big it is

Deliverables go straight from the browser to object storage, split into parts and uploaded in parallel. A dropped connection resumes from the last completed part rather than starting the file again.

Nothing is transcoded, resized or re-encoded. What is downloaded is byte-for-byte what was uploaded, which for a graded master is the only acceptable answer.

4 — Someone decides

An Owner or Admin approves the version, or sends it back. Sending it back requires a reason — the server refuses the request without one, not just the form. A rejection with no explanation is the exact friction this product exists to remove.

5 — The next version lands beside the last

Version 2 does not replace version 1. Both stay downloadable, each carrying its own verdict, reviewer and note. Months later, “why did we reject the first cut?” still has an answer, and it is attached to the file rather than lost in a chat.

Who can do what

Roles are per workspace, not per person. The same account can be an Admin for one client and a Contributor for another.