--- title: "How We Film Our Product With Claude" description: "Issue #013 of How We Grow: the homepage wasn't converting, so Lambert built a Claude skill that films Kai from our own codebase. The two options he ruled out, how the skill works, and what the first homepage test said." canonical: "https://hirekai.ai/blog/how-we-grow/013-how-we-film-our-product-with-claude" date_published: "2026-09-11" last_updated: "2026-09-11" article_type: "how-we-grow" author: "jim" --- # How We Film Our Product With Claude ### Key takeaways - **The homepage wasn't converting, and the team agreed people needed to see the product working.** That meant video. The open question was how to make it. - **Lambert ruled out a motion designer and a screen recorder.** A designed film costs a couple of thousand dollars and goes stale as the product changes. Screen Studio recordings are slow to stage and full of private data to blur. - **He built a Claude skill that films Kai from our own codebase.** Describe a story, review real stills, then render. Every story ships as a desktop cut and a phone cut, and every correction becomes a rule for the next film. - **Cheap and fast is the point.** It lets us test which story converts instead of betting on one. - **The first test pointed the right way without proving it.** The new homepage, with a film in the hero, converted 5.75% of visitors to a sign-up click against 3.85% for the old one, at p = 0.083. Lambert shipped it on the direction. ## Introduction This is How We Grow, our weekly log of what we're doing to grow Kai. It's mid-September, a month out from the official launch, and the work has changed shape. We have real users and paid campaigns now, so we find out fast whether something works, and we've gone from two-week sprints to one-week sprints to shorten that loop even more. This week's topic started with a page that wasn't doing its job. Lambert has been on the homepage and our landing pages for weeks, and the homepage wasn't converting. What he built to fix it is a Claude skill that makes product films straight from our codebase. I asked him to walk me through why he built it that way and how it works. ### Watch or listen Watch on YouTube: https://www.youtube.com/watch?v=1BStNXj4Ecc Listen on Spotify: https://open.spotify.com/episode/36vUY18L0q6Vy2Zi6zFRGG ## Lambert weighed 3 ways to film the product It started with the team around a table, asking what someone should see in their first seconds on the site. One camp wanted to show what Kai is worth without showing the product. The other wanted the product and its value together, which meant video, and after a few more rounds that's where we landed: films of the real product running a real flow. That left the question of how to make them, and Lambert worked through 3 options. **Hire a motion designer.** The polished option, and the first one out. It costs a lot, and at our stage the product and its UX change constantly. A film paid for this month can show an app that looks different the month after, and that money's gone. **Record the screen ourselves.** That means Screen Studio: you run the flow in the app while it records, then polish it with zooms, highlights and on-screen shortcuts. Lambert has made plenty of these for our [What's New page](/whats-new), and it's slow. Kai has a lot of features, and filming one moment means making it happen first. To show a notification, you have to get one to fire. A meeting recorder like Granola or a dictation app like Wispr Flow reaches its main feature in two steps, and Kai doesn't. A real account is also full of things nobody should see, so his What's New recordings meant blurring information in the edit. And sometimes the app didn't do what he expected mid-take, which makes a good bug report for the devs and a bad video. **Have Claude build the films.** This is the one he picked, and Lambert doesn't think we could have pulled it off 3 months ago. He gave Claude our whole knowledge base and the app's codebase, then rebuilt Screen Studio's behaviour from scratch, without its interface: the moving cursor, the zooms, the highlight on a click. It took him 3 or 4 days to get results good enough to start. Since then, a film starts with Lambert telling Claude the flow he wants. Nothing is recorded, so a film shows exactly what the story needs. There's no account with thousands of emails behind it and nothing to blur. Everyone on screen is invented, apart from the team. Lambert calls it faking things in the good way. ## How Lambert's films get made ### Each film is built from the app's own code The pipeline is wired to the codebase, and that's the part that pays off over time. A new film picks up the product as it is that week, and updating an old one means asking Claude to redo it. Under the hood, each film is a React scene drawn from a replica of Kai's interface, generated from the app's own source, then filmed frame by frame into an mp4. The same command always produces the same file, so when the design moves, the films can be shot again to match. For the episode I pulled everything Lambert shot between 27 August and 9 September into one showroom page: 6 films and 9 cuts in 2 weeks, not counting the 2 that got pulled. Each film shows one workflow Kai handles. These are the two I put on screen during the call. **The Handoff Cut: an email becomes a task you hand to Claude.** **The Conflict Cut: a new call lands on top of a 1:1.** This one's on our homepage now. ### The skill storyboards in stills before it renders Lambert packaged the whole workflow as a Claude Code skill called `film`. Running it opens a long conversation with Claude, and the loop goes like this: 1. **Describe the story in plain words.** His example on the call was the morning brief: a notification from the morning brief arrives, you open it, you select the tasks that are overdue, a suggested action offers to plan them today, you click it, and they land on the calendar for you to accept or not. 2. **Claude scopes it into beats.** One click per beat, and every action Kai takes is checked against our product docs before anything gets animated. 3. **Claude storyboards it as stills.** Before any video exists, it exports 6 to 10 PNG frames from the scene it built, one per beat, with a note on what happens in each. This is where Lambert pushes back hardest. His first version of the skill went straight to video, and every round on video eats tokens. Arguing over stills is cheap. 4. **Render the film.** Once the stills are right, Claude captures the mp4. 5. **Polish it in 2 or 3 more rounds.** Usually a highlight lands on the wrong thing, or the cursor moves in a way that doesn't read. 6. **Turn every correction into a rule.** When Lambert spots something wrong, he tells Claude, and Claude writes it into the film rules. The next film starts with it fixed. **That story as stills, one per beat.** They're the kind of frame the skill exports for review, rendered from the same scene the film was shot from. They come from the finished version, though. The drafts Lambert pushed back on lived on a review page, not in our repo. 1 · The brief arrives at 8:42 2 · Kai opens on Triage, the brief written in 3 · Three tasks selected, then Schedule today 4 · Kai looks for open time 5 · Kai asks where the blocks go 6 · The sessions land between the meetings **The Morning Brief Cut, from that description.** Those rules compound, and some have already overruled the Screen Studio behaviour Lambert rebuilt. Since 4 September a film gets no camera moves unless it can't be read without one, and the highlight on each click carries the eye. The spotlight, where the frame dims around one element, is kept for Kai's own actions, 2 or 3 per film. As Lambert put it in that review, nobody cares that someone clicks "end the meeting". You can watch that happen to one story. Before it was the Handoff Cut, "you received an email" was the first loop Lambert made for the homepage hero, on 28 August, and it played entirely inside Kai's window: the email becomes a task, and the task gets booked for tomorrow. **28 August: the first loop, inside Kai.** On 1 September the story got its handoff. A Mac notification opens Kai on the email, the suggested task gets accepted, and Do it with Claude stages the prompt in Claude for you to send. **1 September: the same email, handed to Claude.** The Handoff Cut further up is the 8 September reshoot, with the dock and menu bar in frame. The camera moves once, and the prompt is lit before you press send. ### Every story ships as a desktop cut and a phone cut The desktop cut plays on a macOS desktop, dock along the bottom and menu bar across the top, because Lambert wanted people to understand this is what they'll actually see. It also lets a film follow Kai's work into other apps, since a lot of it ends up somewhere else: a prompt waiting in Claude, a reply in Slack. And because the desktop is built rather than recorded, nobody sees Lambert's own apps or his private conversations. The phone cut is the same story on an iPhone, running Kai's mobile app, made by the same process. It exists because of the homepage. On a phone, the desktop film shrinks to about 354 pixels wide and the app's text inside it lands at around 4 pixels, which nobody can read. So a phone visitor gets the phone cut, a laptop visitor gets the desktop one, and the phone cut quietly tells people there's a mobile app. Recording both by hand would double the work for every story. Here one description produces both. Lambert keeps them small, because a heavy video is its own conversion problem on a phone connection. Our tests fail any video on the site over 1 MB, and these land between 290 and 900 KB. **The Conflict Cut and the Morning Brief Cut, cut for a phone.** ## Cheap films let us test which story converts When I asked Lambert to boil it all down, he went straight to what we don't know yet: which story makes someone stay on the page and click through to the app. Pay a motion designer and you've paid for one story. If it's the wrong one, you find out a month later, holding a great video that shows the wrong thing. With the skill he can film any story he likes, take ideas from the devs or from Danny, who runs our customer support and hears what people ask for, and put the stories up against each other. For me that's the main takeaway. This workflow makes high-quality product films cheap, and because they're cheap and fast we can make dozens, put them on the site, and test which hook and which story work. Hire a video creator and we pay a couple of thousand dollars for one film, which might be great and still turn out not to be the one we need. We're early and learning a lot every week, and at this stage cheap and fast is worth more than one perfect film. ### The new homepage converted better The first test put the new homepage against the old one. From 29 August to 7 September, half of our homepage visitors saw the new version, with a film in the hero, and the other half kept the old one with an illustration. The new side kept changing while it ran: on 1 September the Conflict Cut replaced the first film, and the rest of the page was redesigned around it. On the new page, 5.75% of homepage visitors clicked a sign-up button (44 of 765), against 3.85% on the old one (29 of 754). That's 49% better, relative. It isn't statistically significant (p = 0.083), and Lambert shipped the new version as the only homepage on 8 September on the strength of the direction. Now the question is which film. Lambert is 99% sure the story on the homepage today isn't the best one we have, so the next tests put story against story, each with a headline written for it. ## Lambert credits the models, I credit the design This is where we didn't agree. Lambert reminded me that after our first hackathon, back in March, I'd asked him to try making videos with Remotion to explain what we wanted to build, since the product itself had no real design yet. He says what he makes now is way better. His read is that the models are what changed: a film moving smoothly from the app to Slack and back is something he doesn't think anyone could have made 6 months ago. I pushed back. In March we had no design and no brand. The design system and the brand we wrote up in [#004](/blog/how-we-grow/004-how-we-built-a-brand-ai-can-run) and [#005](/blog/how-we-grow/005-we-designed-our-site-without-figma) give Claude something exact to build against, and I think that does an enormous amount of the work. Lambert agrees that a well-documented design and codebase are what make any of this possible. He still puts most of the jump on the models. We left it there. ## What broke, and what the test didn't prove **The test pointed the right way without proving it.** At p = 0.083 the result isn't significant. Confirming a lift that size would take about 1,990 homepage visitors per arm, and we had around 760. Two thirds of them came from one place, too: 1,007 of the 1,255 homepage visitors on 3 and 4 September arrived through one creator push, the first collab we covered in [#012](/blog/how-we-grow/012-how-were-positioning-a-saas). And the new side was never just a film. It started as a redesigned hero, headline and layout included, and from 1 September it was a redesign of the whole page, so the 10 days pool more than one version of it. The result says the new page did better. It can't say the film is why. Lambert made a product call on a direction, and that's how we're writing it down. **Story-against-story tests will be slow at our traffic.** Lambert wants to iterate week after week. Outside that spike, though, the homepage gets 10 to 25 visitors per arm per day, and at that rate one test that can settle a difference this size takes 2 to 3 months. Weekly iteration only works if we point traffic at the question, with a creator or paid push timed to the test, or run the stories on our paid landing pages, where the traffic already is. **It broke twice in 2 days.** On 8 September the Brain Dump Cut shipped with its chat, task list, calendar and brief drawn by hand instead of built from the app's components. It failed an audit with 42 defects, 13 of them against rules already written down, and was pulled the same day. The next day a phone film went live on one of our landing pages as a recording of our own 404 page: its capture script pointed at a route that didn't exist, and the stills that got reviewed came from a different script. It was replaced within the hour. Both are rules now: show the app exactly as it is, and check frames from the final file, not the stills before it. ## What's next This started as a fix for one page. The part Lambert finds most interesting is that the answer works anywhere: the rest of the site, our emails, social. I'd add the creators and ads. **Films that keep up with the product.** When something relevant lands in the changelog, Lambert wants to get flagged, by Kai or through Claude and GitHub, and have the affected films shot again. Today that happens when he asks for it. The automatic version is still to be worked out. **Teasers for social, from next week.** Shorter films with smooth transitions, made to share. **The launch video, in about a month.** Lambert plans to mix these films with real footage of us talking and edit the two together. **Films for creators.** The creator program I run can hand each creator a flow built for their audience, and Lambert says that isn't hard to make. **Sound.** Clicks, typing. Claude wrote the code for every frame, so it knows exactly when each click lands, which is where a sound effect goes. **Eventually, motion design straight from AI.** The kind of animated SaaS video you see everywhere, generated rather than designed. Lambert thinks one of the newest models may already be able to do it. If you want to follow along, the whole series lives at [How We Grow](/blog/how-we-grow), and the [changelog](/whats-new) is the receipts of what we ship week to week. Sign up and each issue lands in your inbox, along with early access to what we're building. ## Sitemap See the full [sitemap](https://hirekai.ai/sitemap.md) for all pages.