The question small-team tracking has to answer
Strip production tracking down to its job and it is one question repeated: for each shot, is each department done? Is comp delivered on SH040? Is roto delivered? Is fx delivered? A studio of two to ten people lives and dies on that grid - because when the whole team can see the shot list, the missing information is never "what shots exist," it is "which cells are still empty." That is a shot-by-task matrix: shots down one side, departments across the top, each cell a delivered / not-delivered against the current cut.
The enterprise platforms answer this question too - but they answer a hundred others alongside it, and you pay for all hundred. For a large facility that is the right trade. For a small team it is a database, a configuration project and a per-seat bill wrapped around a grid you could read at a glance.
Why per-seat platforms fit small studios badly
The mismatch is structural, not a matter of taste. This is a companion to our fuller ShotGrid alternatives for small studios piece - the short version:
- Per-seat pricing punishes flexing. Small studios staff up and down per project. On per-user pricing, adding a sixth artist for a busy month is a billing decision, and the seat you stop paying for is admin every time the roster changes.
- The setup phase costs more than the software. These platforms assume someone configures pipeline, statuses and automations. On a small team that someone is an artist not making shots for a week.
- You use a fraction of it. Bids, review rounds, department dependencies, capacity planning - powerful, and mostly idle when there are thirty shots and everyone can see everyone's screen.
So small studios fall back to a spreadsheet, which is free and flexible right up until the cut changes, three shots get new versions, nobody updates row 40, and the grid becomes a rumour. The realistic choice has been an over-built platform or an under-maintained sheet. The matrix should be neither.
Make the matrix derive itself
The reason the spreadsheet drifts is that a human has to update it, and the update is the thing that gets skipped under deadline. The fix is to stop having a human assert the status and instead derive it from things that are already true: the cut (which shots exist and at what version) and the renders folder (which tasks have actually landed on disk). If a comp render for SH040 exists at the cut's version and covers the range, the comp cell is green - because the file says so, not because someone remembered to tick it.
Set the matrix up once - list your departments, tell it your naming convention so it knows which files are which task - and it recomputes every time you re-scan. A shot that dropped out of the cut leaves the grid; a task that got a new version updates its cell. The grid is a view of reality, not a second copy of it that can disagree.
Local-first, flat-priced, no setup
The other half of fitting a small studio is not charging or configuring like a big one. Cutlist Tracker is local-first - the folder is scanned by file name in your browser, pixels never leave the machine, and team sharing happens through a small cutlist-status.json written into the project folder, so your file server is the sync with no server to run. And it is flat-priced per studio - A$29/mo for the whole team, not per seat - so hiring your sixth artist never triggers a pricing meeting.
Its per-department matrix is exactly the shot × task grid above, derived from the cut you imported and the renders folder you scanned, showing each department delivered or outstanding against the current cut. Alongside the conform check, cut diff and delivery manifest, it is the small-studio subset of production tracking - the part you actually use - without the platform, the per-seat bill, or the week of setup.