When a Shot Planner Becomes a Production Management Platform

The seventh problem: a project doesn’t belong to one person — it belongs to a team of thirty. The product had to grow up to match.

CineLog launched its public beta in February 2026 with a clear identity: a planning tool for the director and the DP. The whole product narrative was about solo creative work — write the script, generate the shot list, sketch the storyboard, plan the days.

Within the first week, the same question kept arriving from beta users in different forms:

“How do I get this to my AD?” “Can my producer see the shot list without editing it?” “Can the gaffer see only his department’s stuff?” “Can I invite the line producer without giving her access to my script?”

We’d known crew collaboration was coming. We’d planned to address it in stages. The volume of the demand pushed it up the roadmap from “later this year” to “the next eight weeks.”

This is the article about the moment CineLog stopped being a planning tool and started being a production platform.

Cast & Crew: the missing center of gravity

A film production isn’t a list of users. It’s a structured organization. There are groups (Production, Camera, Sound, Locations, Art, Wardrobe, Hair & Makeup, Editorial), departments inside each group, and specific roles inside each department. A “Best Boy Grip” is a real job that sits under “Grip” which sits under “Camera.” That hierarchy isn’t optional — it’s how every union sheet, every call sheet, every department head conversation is structured.

So we built Cast & Crew around that hierarchy. Three levels: Group → Department → Role. Hundreds of canonical roles populated from industry-standard listings, so when you spin up a project you don’t have to manually create the concept of “Director of Photography” — it’s there, alongside its slot in the Camera department, ready to be filled.

The two-view design followed naturally:

Cast & Crew view — the structured org chart of the production. Visualized as a kanban-style board on wide screens, or a dense vertical table for users who prefer density.
Contacts view — a flat Rolodex of every person in your workspace, scoped per-workspace so you don’t lose them when a project ends.

A contact lives in the workspace. A role lives in the project. Assigning a contact to a role is the bridge.

Vacant Slots: planning without knowing who

The single most useful concept that came out of this design phase was the Vacant Slot.

Productions plan roles before they fill them. You know you need a Director of Photography in week two of pre-pro, but you don’t have one yet — you’re in conversations with three. A traditional contacts-based system makes you wait until you’ve hired someone before you can put them on a call sheet.

In CineLog, you create a Vacant Slot for “Director of Photography” and you can already reference it: on the call sheet, in the access control rules, anywhere the role belongs. When you finally hire someone, you assign their contact to the slot and the assignment propagates everywhere automatically. Their name appears on every call sheet, every schedule, every shot list cell that references the role.

This lets the planning UI parallel the actual planning workflow, which is rarely “find a person, then write them down” and almost always “write down what you need, then go find someone.”

Role-Based Access Control: the part we knew would be painful

Now the hard part. Permissions.

The naive approach is per-user permissions: each invited person gets their own checkboxes. This is operationally a nightmare. You add ten people to your crew, you’re checking a hundred boxes. You change your mind about what an editor can see, you have to update every editor on every project.

We built permissions around roles, not users, with three priority tiers:

Department baselines — Production staff get a broader default; Camera staff get camera-specific access; everyone gets a sane default for their function.
Role refinements — A Casting Director needs slightly different access than a Producer; the role template overrides the department baseline where relevant.
Project-specific overrides — Sometimes the Project Owner wants a specific exception: this Gaffer, on this project, gets to see the script. A targeted toggle in the Cast & Crew UI overrides everything else for that role in that project only.

The system resolves these at runtime: department default merged with role template merged with project override. We called this “merge-at-resolution” — the user never sees the inheritance, they just see the final state. Behind the scenes, an exhaustive test suite validates the priority logic across thousands of combinations to ensure no permission ever leaks between roles or projects.

The first version of this was confusing for users, because we exposed the inheritance directly and asked them to reason about it. The second version hid it: you see “this role can edit shots” or “this role cannot,” with a small indicator showing whether that’s a default or an override. You can change the override; you can’t accidentally break the default.

The Intent Toggle: invitations as a side effect

The traditional invitation flow looks like: open a form, type an email, send the invite, get an acknowledgment, hope they accept it, find them in another list and assign them to a role. Six steps, three screens.

We collapsed it. In the Role Details dialog, there’s a single switch labeled Access. Flip it on:

If the contact has a CineLog account already, they’re added to the project transparently. No invitation email, no waiting.
If they don’t have an account, an invitation email is sent to them automatically, with a deep link that lands them inside the project the moment they sign up.

Flip it off and their access is revoked immediately — propagated to their device in real time over the sync engine.

The result is that the question “is this person on this project?” becomes a one-toggle answer, and the system handles the actual mechanics behind it. We can’t overstate how much faster this is to use than the traditional flow. It’s the kind of UX win that only emerges from being willing to redesign an entire flow once you’ve understood what the user actually wants.

Real-time re-bootstrap

The most subtle problem in this whole feature set: what happens when a user’s permissions change while they’re using the app?

The first AD has “view only” access. The director, mid-meeting, decides to upgrade them to “edit.” The first AD shouldn’t have to log out and back in to see the change.

We added a hook into the sync layer: when permissions change, the affected client re-downloads the project chunks it now has access to, in the background, while the user keeps working. The new capabilities appear in the UI seamlessly. They never see the seam.

This kind of thing is invisible if you do it right. Done wrong, it’s the difference between a tool that feels alive and one that requires a logout-login dance for every change.

The Updates page: who did what, and when

The moment you have a whole crew in the same tool, a new question becomes interesting: who did what, and when?

Film production is a highly systemic process. Three people on the same call sheet making small adjustments in the same hour. The script supervisor updating a scene description. The AD reshuffling tomorrow’s day while the DP is still adding shots to it. Without a record of who touched what, it’s easy to walk into a morning meeting and find the document slightly different from what you remember leaving last night — and have no idea who did it or why.

So we added an Updates page: a single chronological feed of everything that’s happened in the project, with the name of the person who did it and the time. Scene assignments, banner moves, role hires, permission changes, call sheet edits, sendouts — all of it, in order, grouped by day, filterable by type.

The cheeky version: producer didn’t get the call sheet email? You know exactly who to blame. (Kidding. Mostly.)

The serious version is the real one. Before the morning’s first meeting, you scroll the feed and refresh your memory on what changed yesterday. You see whether the thing you were about to do has already been done by someone else. You spot the small fixes that happened in a department you weren’t watching. For productions with rotating responsibilities across days, the Updates page doubles as a handoff document: what the day went through, what got changed late, what was pending when the last person logged off.

It’s a small feature with an outsized effect on whether the team feels like they’re working together on one document, or whether they’re working alone on copies of it.

Pricing: every crew member, no extra seats

This part is a bet. We don’t yet know whether it’ll turn out to be a clever move or a disaster.

Every other tool in the production-management space prices per seat. You add a person to your team, your invoice goes up. We took the opposite stance: when you invite your crew to a CineLog project — ADs, DPs, gaffers, sound mixers, costume designers, all the way down to PAs — none of them cost extra. Your subscription is your subscription. The rest of the crew is in.

The reasoning is grounded in how productions actually use software. On any given project, maybe three or four people are actively editing — the director, the 1st AD, sometimes the DP or producer. Everyone else is reading the parts that apply to them: call times, locations, their department’s section, the day’s schedule. Charging fifty per-seat fees for what is functionally read access felt wrong, both economically and as a way of building a tool.

Two bets sit underneath the decision:

Real-time collaboration only matters when the crew is actually in the tool. If half the people are reading PDFs the AD emailed them at midnight, you don’t have collaboration — you have a one-way broadcast with delivery lag. Inviting the whole crew makes CineLog the shared workspace it’s supposed to be, with everyone seeing changes the moment they happen.
Crew turnover is the most powerful distribution channel we have. A camera assistant who uses CineLog on three productions this year is going to bring it up on her fourth. A sound mixer who got comfortable with the call sheet view doesn’t want to go back to PDF attachments. Letting people experience the product on someone else’s project is how the tool spreads.

The obvious counter is that we’re leaving revenue on the table that every other vendor in the space takes for granted. We know. We’re taking that risk on purpose. We’d rather have the entire crew of a production using the app than have half of them locked out because the producer didn’t buy enough seats.

We’ll find out whether that math was right over the next year or two.

What it looks like today

You spin up a project in CineLog. You open Cast & Crew and create slots for the roles you know you need — Director, DP, 1st AC, Gaffer, Sound Mixer, Art Director. As you hire each one, you add them to your Rolodex and assign them to their slot. As you flip on their Access toggle, they get an email and end up inside your project with exactly the permissions their role deserves. You change a permission three weeks into pre-pro and it propagates to their device while they’re using the app.

The crew is in the tool. The tool is the production.

That sentence sounds obvious in retrospect. It wasn’t obvious before. The pivot from “a tool the director uses alone” to “a tool the production uses together” was the largest scope expansion in CineLog’s life so far — and the one that turned customers from beta users into committed adopters.

The lesson, distilled

If you’re building software for a team-based industry, your data model has to acknowledge teams from the beginning, even if your v1 feature set is single-player. We had workspaces and projects baked in from month one (covered in Article 4) — which is the only reason this expansion wasn’t a from-scratch rewrite of the entire data model.

The features were new. The architecture was waiting for them.

Next: Designing Call Sheets That Actually Work On Set — the feature that, more than any other, validated the platform.