A production accounting platform for film and TV

Context

Film and TV productions run their own books: budgets per episode, payroll for crews under union and studio rules, timecards, expenses, vendor bills and the production’s general ledger. This platform covers all of it. It’s a large React 18 and TypeScript single-page app, more than 700 UI modules in a feature-sliced architecture, on a Ruby on Rails JSON API.

My role

I’m the frontend developer, working with a backend developer and a QA cycle through written API contracts and staged releases. I’ve been on it for several months, and it’s ongoing. I own the frontend architecture, integrate the third-party services it depends on, and introduced shared conventions and engineering-to-product handoffs.

The problem

Numbers have to balance to the cent, and workflows have to mirror real union and studio rules. A timecard that lands in the wrong stage delays someone’s pay. A journal entry that posts out of balance corrupts the ledger. The interface has to be dense enough for accountants who live in it all day, and strict enough that the wrong action can’t happen.

Key decisions

Feature-sliced, from app down to shared

At 700+ modules, the cost of a change is mostly the cost of finding where it goes. Feature-sliced layers give every module one obvious home, and imports only point downwards. It takes discipline to keep a feature from reaching sideways into another, but the codebase stays navigable as it grows.

Typed API layers, permissions from the server

Every endpoint goes through a typed API layer with TanStack Query. Role and permission gating per project is driven by capability flags from the server, so the UI never guesses what someone may do. Global error handling turns backend validation errors into plain language. The cost is more plumbing per endpoint. The benefit is that the frontend can’t drift from what the API actually allows.

Confirm every fix in a browser before it ships

Each QA finding is fixed in a small, documented commit with a matching test-guide entry, and confirmed with Playwright against mocked APIs before release. That’s slower than pushing a fix and waiting for QA. It also means QA re-tests a known change instead of hunting for it.

What I built

Production accounting

A cost report, and a trial balance with drill-down. Journal entries as full documents: a spreadsheet-style line grid, paste or file import with column mapping, and lines that must balance to the cent. Corrections that move all or part of a posting to another account, or change only its coding. Suspense item tracking and period-close checks.

Payroll

A multi-step pay-run wizard with batches by department, a cash approval step, check dates the payment processor can meet, late-timecard handling, supplemental runs and overpayment recovery.

Timecards

Time entered to the minute, a four-stage approval queue with send-back to any earlier stage, and on-set daily timesheets that match the union paper forms column for column.

Budgets, bills and the platform

A budget per episode for TV series with a side-by-side season view; locked budgets that change only through approved overages; budget-line coding across invoices, bills and purchase orders. Vendor bills carry an audit trail of who entered and approved them, with studio-level self-approval rules, and projects can be funded through more than one banking provider. One login works across several companies, with studio-level accounting presets.

Outcome

Accountants, payroll staff and department heads run a production’s books in one app, from the first timecard to period close, with the UI enforcing the rules that keep the numbers right.

Stack

React 18, TypeScript, Vite, TanStack Query, TanStack Table, react-hook-form, Tailwind CSS, shadcn/ui, Playwright. Rails JSON API, built by a colleague.