The first version of Studio Backlot went in the trash.
It wasn’t broken. It worked. But it had wandered so far from the look and feel of our brand portal that it felt like a stranger wearing our clothes. The brand portal is as close to perfect as I can get it, and anything new had to look and work almost identically on the parts they share. So on August 29, I deleted everything (code, schemas, decisions, all of it) and started again from an empty folder.
Fifty-three days later, Honeycutt Inc. runs its productions on Studio Backlot, our suite for creative briefs, AV scripts, call sheets, and delivery notices. Claude Code wrote nearly all of it. I wrote almost none of it, and I made every decision.
Here’s how that worked, what went sideways, and what I’d tell anyone thinking about building this way.
Rule one: the interview comes before the code
Our brand guidelines describe AI as a bored intern who’s brilliant at the stupid stuff and has almost no taste. Useful. Never in charge. That was the operating model.
The second attempt started with a written build prompt that set hard rules. Interview first. Write a spec and wait for approval. Present a plan before every phase. Flag conflicts instead of quietly resolving them. Don’t carry anything over from attempt one.
So the first day produced no code at all. Claude interviewed me one question at a time about how a Honeycutt Inc. production actually moves, from brief to script to voice session to shoot to delivery, and what every tool we used was costing us. That became a six-part spec. I approved it that evening, after settling the three places where my own requirements contradicted each other. (Turns out I wanted both “desktop tools” and “a call sheet that works on a phone at 6am.” Both survived, in different rooms.)
Rule two: don’t fork, extract
Attempt one died of drift, so attempt two made drift structurally hard. Instead of copying the brand portal’s code, Claude pulled the parts both apps share (the shell, search, wiki, comments, notifications, feedback, and design tokens) into one versioned internal package that both apps install.
I handed that job over on a Saturday night with one instruction: merge each piece when the tests pass, and be done by morning. It was. Ten pull requests against the brand portal, each one gated on the portal’s full end-to-end suite passing with its screenshots unchanged. Version 1.0.0 shipped before breakfast.
Now a fix to the shared header lands in both apps at once, and “drift on a shared surface” is a release blocker, not a matter of taste.
The loop: plan, rule, build, demo, repeat
Every phase after that ran the same loop.
- Claude writes a plan. What’s in the phase, what’s out, and a numbered list of proposals for every decision it can’t make on its own.
- I rule on each proposal. One question at a time, recommended option first. Phase six had 25 proposals. Phase seven had 18.
- Claude builds in slices. Each slice is one pull request that merges only when CI is green.
- I test it, and the demo becomes a feedback round. The creative brief alone went through seven rounds and 41 notes before I was happy with it.
Most of the time I took the recommendation. That’s not the point. The point is that I was asked. A plan that buries a decision inside a commit message is a plan that decided something for you.
Taste doesn’t survive a context window, so write it down
AI has no memory between sessions unless you give it one. Every time I corrected something, the correction became a short note that every future session reads. “Row actions appear on hover.” “Arrangeable lists are sorted by dragging.” “The same thing in two places should look and act the same.” “Findings must be actionable.”
By the end, there were 235 of these notes. Some are rules of taste. Some are scar tissue, like “a migration that drops a column ships in two parts.” Together they’re the closest thing the project has to institutional memory, and they’re the reason a session in October builds the way one in August did.
Security and privacy first, not later
Permissions are the part of an app that’s easiest to get almost right, which is the same as wrong. So the permission model was written as a test suite before any feature that depended on it. Every table in the database starts locked, and access is granted explicitly by row-level security policies that enforce who can see and touch what.
The first version of that suite caught four permission defects before a single screen existed. It’s 120 test files now.
Privacy got the same treatment. We decided early that clients would never have to hand us personal information just to do their part. A link, plus a password when a project needs one, opens a document for review. If a client wants to comment, we ask what to call them, and their initials are fine. The easiest personal data to protect is the data you never collect.
Things that bit us
Shipping fast means meeting bugs fast. A few favorites:
- Our own style guide broke the downloads. House style puts em dashes in titles. HTTP headers can’t carry them. So every document named exactly the way our brand guidelines say to name it returned an error when you tried to download it. The fix was a standards-compliant filename header. The lesson was humbling.
- The flaky test was three bugs wearing a trench coat. A test that failed on a different line every time turned out to be a database connection that reset itself on every fresh compile, an editor racing its own refreshes, and a test that didn’t wait for its own writes. Twelve passing runs in a row had proved nothing.
- A spam filter spent the sign-in links. A guest’s magic link “expired” four times in a row. Their email security scanner was clicking the one-time link before they could.
- Presence looked broken because it was working. I reported that the “who’s here” indicator was dead. I was alone in the document, so it showed nobody. It now says, “Nobody else is here right now.” An empty healthy state reads as broken.
- One bad minute shouldn’t blank a whole morning. A single failed weather lookup at 5:58am would have cached the failure for an hour, leaving the call sheet’s forecast empty right as the crew checked it. Failures now expire in about a minute. Good answers keep their full life.
Then we went looking for more
Fast doesn’t mean unchecked. Three times, Claude ran a whole-codebase bug audit with parallel reviewers reading different areas. They found 73 bugs, then 71, then 80. Each fix shipped with a test that fails before it and passes after. A dedicated security review in October produced 47 verdicts and 21 fixes. An accessibility sweep tested 82 screens in both light and dark themes against WCAG 2.2 AA, and it stays in place as a gate on every merge. We deliver captions and audio descriptions for a living. Shipping an inaccessible tool would have been a special kind of irony.
By the numbers
- 53 calendar days, first commit to today
- 44 days with at least one commit
- 393 commits merged to main
- ~166,000 lines of app code
- 172 database migrations
- 51 end-to-end test files
- 48 commits on the busiest single day
- 235 standing notes in the project memory
What’s next
Two features are up next, and both are close: a full storyboard editor, and an asset file drop where clients send us the files a project needs.
The storyboard editor is the one I’ve been waiting for. On day one, the build prompt told Claude to treat scene images as first-class data, so that a storyboard would be a rendering problem later instead of a migration. We’re about to find out whether that bet paid off. Both features go through the same loop as everything else: interview, plan, rulings, slices, and a demo I poke holes in.
What I’d tell you
Decide everything. Type almost nothing. The AI is a fantastic builder and a terrible product owner. Keep the second job.
Make it interview you. Most of what went right was settled on day one, before a line of code existed.
Write your taste down. Every correction you don’t record is one you’ll make again next week.
Test the permissions before the features. Retrofitting security is how you end up with an app that’s almost secure.
Go looking for bugs on purpose. Users find the ones you didn’t look for, usually at 6am.
Studio Backlot is in daily use now, running real productions. The script knows about the brief, the call sheet knows about the script, and the call sheet knows it might rain. The first version knew none of that. It just looked like a stranger wearing our clothes.
