2026
A casting platform, designed, directed and shipped end to end
Result: 200+ actors sourced, about 30 of them selected for the roster. On The Wandering Earth 3, I had placed 13 actors for 95 shoot days with nothing but spreadsheets and messaging apps. The platform, which I led end to end, secure and reachable from mainland China, exists so that no production has to run that way again.
Read the full case
Where it comes from
It starts with The Wandering Earth 3. I was coordinating the foreign cast of a Chinese production, and my only tools were messaging apps, email and spreadsheets. Could the work really be done that way?
Clearly not. So after the shoot I started an agency to do this work properly, then built the tool it runs on.
What I put together
A single roster, shared by three kinds of users. First the actors, who apply and keep their portfolio current. Then the agency, which evaluates, admits and presents them. Finally the productions, which open a private casting room, compare a shortlist, and book.
Every actor also gets a branded PDF résumé, rebuilt whenever their credits change.
From a self-tape to a paid actor, one pipeline
A form would have been enough for a brochure site. A casting agency, though, needs its whole chain, and each side has to work in its own space.
Actors
- They apply, then upload photos, showreels and self-tapes.
- Their files are compressed, renamed and sorted automatically, so that a production, wherever it is, downloads a clean, structured package fast.
- Their old résumé is read, parsed, then rebuilt as an agency-branded PDF.
- They get a personal space and tools of their own: a profile link they'll want to share, comp cards in one click.
Agency
- It searches the whole roster in seconds.
- It evaluates actors, admits them, then guides their development.
- For each casting, it builds a selection and sends it to the production.
- It remains the filter between both sides: nothing reaches an actor without our sign-off.
Productions
- They receive the selection in a private casting room, where every résumé carries the agency's branding.
- They keep or pass on each actor.
- They book the actors they keep and sign contracts on the platform.
- They follow every actor, from shortlist to set.
Note: every platform screen shown here uses demo data.
Where the difficulty lies
Three sides, a single truth
Actors, agency and productions each see a different slice of the same records. Who sees what, and when? That question is, in the end, the product. So an actor must never learn a production's decision before the agency has approved it, and a production's name is revealed only with its consent.
A market on the other side of the firewall
Yet productions work from mainland China, where Supabase is blocked and most hosting platforms are absent. Hence Cloudflare's edge placed in front of a Singapore server, picked over a cheaper German one for latency to Vietnam.
Heavy files
Showreels and self-tapes are large video files. That called for resumable uploads straight to storage, a video encoding pipeline, and short-lived signed links.
Personal data
Contact details, ethnicity, body measurements, photos, private agency notes: a leak would expose the actors and the agency's trust with productions. Which is why security is the one area where I never gave anything up for speed.
Security
First, I wrote security rules the AI is not allowed to bend. Then I had the code reviewed in several passes, and again after each feature. Fifteen decision records, in fact, cover security reviews and hardening.
- The server stays invisible. Its address sits behind Cloudflare, and it rejects any connection that can't prove it comes from our own domain.
- At rest, sensitive fields are encrypted. Agency notes and evaluations never leave the admin side, and the file a production downloads follows a strict whitelist, with no contact details at all.
- A single login for everyone, with a generic error. So nobody can test whether an account exists. Sessions are short and rotated on every use, and the brute-force lockout can't be dodged by faking an address.
- Backups are encrypted before they even leave the server, and their key is kept away from the storage they protect.
- Finally, public forms are protected from bots, dependency vulnerabilities are triaged, and build tools are pinned to exact versions.
An AI agent writes fast and sounds sure of itself. So most of my job came down to catching where it was confidently wrong.
Working with AI agents: my method
First observation: an AI agent writes code faster than I can check it. The bottleneck, in other words, has moved. And the traps are well known: code that looks right, invented facts, lost context, runaway cost. For each one, I built a safeguard.
Verification
A "make this page responsive" task came back marked finished; on my phone, I still found seven defects, one at a time. So I wrote a verification rulebook every session follows before saying "done" (excerpt below). I also discovered 883 tests that nothing ran before production, and had them wired in. Even so, a go-live audit caught 3 blockers that no automated check had seen.
Invented facts
Left alone, an agent fills gaps with plausible fiction: past clients who don't exist, reassuring numbers, stock photos passed off as our actors, profile links that lead to someone else. Hence a rule: what I can't prove doesn't go public. Copy lives in documents I own, and a mockup isn't allowed to add a claim. Likewise, search-engine data only carries links I supplied. As for placeholder photos, they now fail the build.
Memory
Each session, an agent starts from zero. How do you work over time with someone who forgets everything? By handing the memory to the project itself. A briefing file states the live rules and points to the reasoning; more than 100 decision records keep the why. A progress log is kept after every task, and a written rule forbids re-debating a settled decision: it can only be formally revised. Finally, a separate file lists "commands an agent would guess wrong".
Several agents at once
I run several sessions in parallel, each on its own copy of the code. One day, one of them deployed a stale copy, silently erasing another's fix. Since then, every session checks its drift against the shared branch at startup, and the deploy script refuses anything that isn't the latest version.
Picking the model, counting the cost
Inside the product, the résumé import calls Claude. Does that require a big model? The job is reorganizing text, not perceiving images, so I use the smallest one, Haiku, and send it extracted text, never the raw PDF, which would cost far more. That comes to about 1.5 to 2.3 cents per import, capped at 10 an hour per visitor. Every answer is re-validated against a strict schema; if the AI fails, the import works anyway. I also priced an AI layer for the code map, then dropped it.
Architecture: learn first, choose second
A first stack was offered; I didn't take it. I asked the AI to explain the main architecture options and their trade-offs, read all of it, then made the call myself. Every proposal, I pushed hard: why, how, how fast, under which conditions, for how many users? Sized for real load rather than hypothetical scale, a single server with the video encoder beat pricier managed services. And since productions sit behind the Chinese firewall, anything blocked there was out, whatever its reputation. I also overrule the first proposal when it is wrong: a "you're shortlisted" message still visible after a production had passed, a résumé parser that turned my own 28 credits into 50, a brief form that stored nothing.
What the user sees, the AI doesn't
On my iPhone, in the Arc browser, the bottom of the home page vanished under the floating bar. No test had caught it, and the AI can't open Arc. Three times it tried to guess the bar's height by changing which elements were shown or hidden; three times I tested on the phone and said no, because one version was too cluttered and another removed the scroll cue I wanted to keep. The fix came from restating the problem: I didn't want fewer elements, I wanted the cue to sit exactly on the edge of the bar. In other words, a single number to set. We read it off my screenshot, and on the fourth round I signed it off on the device.
Even its tools get it wrong
First finding: the code map every session read at startup was 54% noise from third-party dependencies. Second finding: the build watchdog was watching the wrong process, 0.9 points away from killing a healthy build. Which is why, before I trust a tool, I have it measured.
My verification rulebook, an excerpt exactly as I wrote it for the agents
I wrote it after a "make this page fully responsive" task shipped, then took several more rounds, because I kept finding defects on my phone, seven of them, one at a time. Yet none had been misdiagnosed: the failure lay entirely in finding them.
- Verify the artifact you ship, over its whole surface. Enumerate it, don't assume it.
- A declared gap is not a covered gap. "Can't test X" means build a way, or say unverified.
- Green checks prove no breakage, never quality. Always look at the finished result the way its user will meet it.
- When you can name why a bug happened, use that sentence as a search across the module. Fix the category, then go find its other members.
- Suspect the fixture when a measurement contradicts the code. A checker that can pass while broken is worse than none.
