Live demo
Say what you want to see. Claude works out what to show, writes a walkthrough of the loupfeed dashboard, and drives it in a real browser — here, in this conversation, while you watch.
loupfeed › Demos
Screen recordings go stale the day after you make them, and automated ones look like a robot filling in a form. loupfeed plays a scenario file the way a person would use your app — the cursor travels, the page scrolls, the typing hesitates — and records the take. Re-run it every release instead of recording it again.
Web and mobile · open source, and free to run yourself
This is the part a screen recording cannot give you and a test runner will not. Every action is paced like a person's, and a walkthrough cannot opt out of it.
Moves to what it is about to press, on a curve, with a beat before the click — so a viewer can follow what is being done and why.
Nothing is pressed unless it is genuinely on screen. No take contains an invisible click that a real person could not have made.
Off-screen things are scrolled to the way a person scrolls — flick, coast, settle — never a jump that gives the game away.
Typed a key at a time, hesitating after words, instead of a field filling instantly with text nobody appeared to write.
The same walkthrough produces the same take. Re-run it next release and the only thing that changed is your product.
A demo here is a document, not a video file. It lives beside your code, goes through review like anything else, and when the product changes you correct a line rather than booking an afternoon to record the whole thing again.
And because it is written down, it can carry what it is meant to prove. Each walkthrough names its milestones — the report resolved to a line of code, the crash grouped with its trace — and every run reports whether they still hold.
A run that no longer proves them fails loudly, instead of quietly demoing the wrong thing to a customer.
That division of labour is the whole design. An agent is good at working out what a demo should cover and bad at making playback look like a person — so it never drives the browser itself. It explores your app, writes the walkthrough from what it actually found, and hands it to the engine to play.
Nothing is hand-scripted against your markup, so a walkthrough does not rot the first time someone moves a button. The agent works from a map of your app that it builds by exploring it, and the map is rebuilt whenever the app changes.
And because the walkthrough is written down rather than recorded, it can be checked. Each one carries the milestones it is meant to prove — the report resolved to a line of code, the crash grouped with its trace — and a run that no longer proves them fails loudly instead of quietly demoing the wrong thing.
A phone has no cursor to follow, so looking human comes down to pacing: how a list flicks and coasts, how long a screen is held before the next tap. The same walkthrough you wrote for the web plays on a device, recorded there — rather than making you keep a second one in step with the first.
Where it stands: mobile playback is newer than the web player. The web side is what runs the demo above.
The launch video, the release note clip and the onboarding walkthrough all regenerate from the same file after a UI change.
A walkthrough carries what it is meant to prove. One that stops playing is telling you a real flow stopped working.
Seeded playback means a re-run is comparable to the last one — no “it looked fine when I recorded it”.
Free to run yourself, forever. Open source, and yours to keep.