Jason Lee's tutorial begins with an ambition that a static app mockup cannot meet: make a self-care companion feel alive. He studies Finch, then builds a different pet-centered prototype called Chewy. The visible workflow runs from reference research and a browser mockup to animated scenes and an iPhone preview.
Claude Fable 5.1 is the planner and coding agent; Higgsfield supplies character and background assets; Seedance 2.5 makes the larger scene animations; LottieFiles supplies a lightweight success effect; React Native and Expo move the prototype onto a phone. The video demonstrates a compelling build process, not a shipped mental-health product.
Watch Jason Lee Build the App
Credit: Jason Lee's original tutorial, published 18 September 2026, and the supplied transcript. Timings, build results, and model preferences below are Jason's demonstration and opinions. The article adds independent implementation checks where the demo leaves work unfinished.
What Each Tool Contributes
- Claude Code with Fable 5.1: maps screens and behavior from the brief, creates the mockup, writes the app, and turns visual feedback into revisions. Jason says the same workflow could be attempted with GPT-6 Astra; the video does not run a controlled model comparison.
- Higgsfield: generates the alligator variations and swamp backdrop from Claude's instructions. Its official connection guide documents agent access; check the current account route and costs before starting.
- Seedance 2.5: animates the character and environment from visual references. Higgsfield's model page lists image-to-video as a supported route.
- LottieFiles: supplies a reusable confetti/check-mark microinteraction when a goal is completed, instead of generating every tiny motion as video.
- React Native and Expo: package the interface for a device preview. Jason uses an Expo EAS build for the iPhone shown at the end.
That split is the useful idea. A coding model, media model, interaction asset, and native build system have different jobs. Asking one model to do all of them obscures where a failed result should be fixed.
1. Start With a Product Map, Not Code
Jason puts a screen recording of Finch's navigation into the project folder and asks Claude to list the screens and features before implementing them. He also gives it a character reference and asks for a new alligator named Chewy. The sequence is worth copying, even when the reference app is different: study what each screen lets a person do, which states change, and how a user reaches the next step.
Finch's own new-user guide describes the goal-to-pet-energy loop that Jason observes. The transferable pattern is rewarding a small real-world action with visible progress. Finch's exact screens, wording, bird, and branded artwork are not a reusable design kit. Jason changes the mascot, but he also acknowledges that a real app should change much more than a demo reconstruction.
Describe the user's goal, screen states, and feedback loop. Tell the coding agent to use references for interaction analysis only, then create original copy, visual language, characters, and layout. Ask for a screen map and acceptance checks before it writes code.
2. Build the First Screens and Test the Clicks
Jason asks for the main tabs and a localhost phone mockup. Claude uses the alligator reference to set the palette, isolates the character from a sticker-style image, and requests a matching lakeside scene through Higgsfield. The first version has a home view, quests, a shop, friends, and a profile. Jason clicks through goals, a skip action, and a shop item, giving the viewer more evidence than a single screenshot.
He also points out the boundary: at 09:45, the backend is not set up. The interface can simulate a purchase or show a currency warning, but that does not prove accounts, durable state, inventory, billing, or synchronization. Treat this phase as an interaction prototype.
3. Add Onboarding, Then Repair It
The next pass maps Finch's long onboarding journey into Chewy's prototype: choose an egg, tap to hatch it, name the pet, move through a few preference screens, and reach a trial-style paywall. Jason shows the generated flow at 12:29. Some images are cropped or broken. He sends screenshots back to Claude, asks it to repair the specific assets, and checks the affected screens again.
This is a stronger lesson than the speed claim. A generated flow still needs state-by-state review: first launch, back navigation, skip paths, selected egg color, pet naming, interrupted onboarding, and returning user. In a real self-care app, the questions and trial messaging also need thoughtful consent, clear pricing, and a way to continue without pressure. The video shows the paywall's appearance, not a verified subscription checkout.
4. Animate the Big Scene; Use Small Assets for Feedback
Jason first asks Seedance 2.5 to make Chewy move and to animate the water and plants. The initial result is lively but unstable: the alligator changes size mid-loop, and the cloud does not loop cleanly. He then gets more specific about the sequence: walk right, return to center, pick up a cup, drink, set it down, and return; leave the cloud still while keeping the water and plants in motion. The second preview follows that direction more closely.
That is a practical animation prompt pattern: define the subject, fixed visual properties, ordered action beats, what should remain still, and the starting/ending state of a loop. Review the rendered clip in context, not only in the media generator. Small assets get a different treatment: Jason downloads a LottieFiles completion animation, adapts its color, and asks Claude to show it when a goal is marked complete.
LottieFiles' licensing guidance says to check the license on each animation, especially before commercial use. The Pinterest mascot reference needs its own rights check too. A visible reference in a tutorial is not proof that a production team owns it.
5. Move From Browser Mockup to iPhone
While the media job runs, Jason asks Claude to build the app with React Native and guide him through an Expo EAS build. At 23:08, he opens an installed app on his iPhone and compares it with the Chrome preview. That matters: touch targets, swipes, animation pacing, and screen cropping can feel different on a real device.
One technical clarification is important. Jason describes Expo Go as unable to use a database or Google sign-in. Expo's own FAQ frames the limit more precisely: Expo Go cannot run arbitrary custom native modules, while it can run libraries included with Expo. For example, Expo SQLite is included in Expo Go in that SDK. Expo recommends development builds for serious projects and custom native capabilities; EAS Build can produce the installable binary.
The phone demonstration verifies an installed preview and visible navigation. It does not, on its own, verify remote data, sign-in, payments, privacy behavior, crash rates, or App Store approval.
What a Production Version Still Needs
- Original rights-cleared design: replace any borrowed reference art, copy, screen composition, or unlicensed animation before distribution.
- Real state and payments: test saved goals across restarts and devices, sign-in, subscription purchase and cancellation, restore purchases, and failure recovery.
- Motion quality: check loop seams, character consistency, video compression, offline behavior, battery use, and a reduced-motion option.
- Self-care safeguards: make no unsupported treatment claims; explain what data is collected, retain only what is needed, and avoid punishing users for missed days.
- Device and accessibility QA: test small phones, large text, screen readers, contrast, tap targets, slow networks, and onboarding paths that do not end at a dead screen.
Jason's video is a useful demonstration of how quickly a designed, animated mobile concept can become tangible. The durable process is to plan the experience, assign each tool a clear job, inspect errors on a real device, and keep the line between prototype and product visible.
Video Chapters
- 00:00 - The Finch-inspired app concept
- 00:56 - What the reference app does
- 02:29 - Tools and build stages
- 04:32 - Plan screens with Claude Code
- 08:43 - First browser version
- 10:22 - Study Finch's onboarding
- 11:52 - Generate onboarding pages
- 12:29 - Inspect and repair onboarding
- 14:02 - Animate the mascot and scene
- 21:23 - Add a Lottie completion effect
- 23:08 - Preview the app on iPhone
Sources and Resources
- Jason Lee: Watch Me Vibe Code an Animated App with Claude Fable 5.1 + Seedance 2.5 (primary video and supplied transcript)
- Finch official site and new-user guide (reference app, not a partner in this prototype)
- Higgsfield agent connection guide and Seedance 2.5 image-to-video page
- Expo development workflow, Expo Go FAQ, and EAS Build documentation
- LottieFiles and animation license guidance