Laravel Video Demos Laravel Package

Product Decisions This Supports

• Demo video as a release artifact, not a project. With v0.18.0 the plan is rehearsed on every screen before anything is recorded, and failures are fed back to the AI as repairs (limits.max_repairs) rather than shipped as a broken video. That makes "generate the demo video in CI / on release" a defensible workflow instead of a one-off marketing task.
• Build vs buy for demo production. This replaces or supplements screen-recording and interactive-demo vendors (Loom, Arcade, Supademo, Navattic, Storylane) for the specific job of "show this flow in our actual app, on realistic data." The make/buy case is strongest where you already have seeders/factories and a Laravel app — the marginal cost per video becomes AI tokens plus a few seconds of rehearsal.
• Whether to support decoupled frontends in the demo program. VIDEO_DEMO_FRONTEND_URL means Vue/React/SPA products are now in scope: recording happens on the frontend's pages while auth and sample data still flow through Laravel. This unlocks demo videos for teams whose product surface is a SPA or a separate marketing/app origin — previously a hard blocker.
• Auth strategy as a demo constraint. VIDEO_DEMO_SIGN_IN covers session (incl. Sanctum cookie SPA), sanctum-token, jwt, and custom via VideoDemo::signInUsing(...) for Passport/SSO. Product decision: is "demo-able with realistic sign-in" a requirement for enterprise/SSO customers, and do we invest in the custom sign-in path to get there?
• Per-video cost budgeting. Rehearsal is free (no AI, seconds), page looks are capped (VIDEO_DEMO_PAGE_LOOKS, default 3, ~$0.01 each), and failed rehearsals consume the repair budget. This gives a predictable cost envelope per video — a concrete input for pricing an internal demo service or gating it to specific tiers/releases.
• Roadmap inputs: self-updating demos. The AI can inspect a page (headings, links, buttons, field labels, secrets hidden) when code can't resolve a label — translation keys, components, DB-driven text. That reduces the "demo breaks when copy changes" maintenance tax, and is a leading indicator for keeping a docs/changelog/onboarding video library current without a human editor.
• Reliability expectations for stakeholder-facing demos. Refused mutations (POST/PUT/PATCH/DELETE returning 4xx, e.g. 422/403/419) now fail the step and route back to the AI, and SPA page checks catch server errors, 401/403s, and redirects to a sign-in page before AI spend. Product call: demos are validated against the app's real behavior, not just visually plausible.
• Use cases this now credibly covers: onboarding and empty-state tours, feature-announcement and changelog videos per release, sales-enablement walkthroughs on seeded accounts, docs and support macros, and PLG landing-page previews — including for SPA frontends with token auth.

When to Consider This Package

Good fit when:

• The product is a Laravel app (optionally with a separate Vue/React/other frontend on its own address) and you can point the recorder at it via VIDEO_DEMO_FRONTEND_URL.
• You have — or are willing to write — seeders/factories that produce a realistic sample dataset. The whole model depends on a copy of the sample database.
• You want repeatable, low-touch demo videos per release rather than a bespoke studio production; you value "regenerate and re-record" over frame-level editing.
• Auth is one of: session, Sanctum cookie SPA, Sanctum token, JWT, or something expressible through VideoDemo::signInUsing(...). Signed-in links only exist while the studio is enabled, so this is safe to keep out of production paths.
• You accept AI-driven planning as best-effort with bounded repair (limits.max_repairs) and are comfortable with the ~$0.01-per-look page inspection budget, or can disable it (VIDEO_DEMO_PAGE_LOOKS=0).
• Your flows are standard CRUD/forms/navigation with labeled fields — v0.18.0's label-to-element fix matters here, and role/label targeting is the primary interaction model.

Look elsewhere when:

• The backend is not Laravel at all, or sign-in and sample data cannot be routed through the Laravel app — the frontend support still assumes Laravel owns auth and data.
• The demo needs heavy post-production: custom motion graphics, multi-track editing, voice-over replacement, brand templating beyond what the app renders. This is a recorder/planner, not an editor.
• The product surface is canvas/WebGL/3D, drag-and-drop-heavy, or otherwise not addressable by role/label/heading semantics.
• Flows require hardware, MFA prompts, email round-trips, or third-party OAuth you can't bypass in a sample environment.
• Compliance or security policy forbids an AI from fetching internal pages, even with secrets hidden — you would need VIDEO_DEMO_PAGE_LOOKS=0 and should verify the degraded path still plans well.
• Demos must be deterministic and byte-identical run to run; AI planning is inherently variable, and rehearsal mitigates but does not eliminate that.
• The team cannot maintain seed data; without fresh, representative sample records the videos will drift from the real product experience.

How to Pitch It (Stakeholders)

To executives: We can turn "make a demo video for the release" from a multi-day marketing/design task into a config-and-run step against our own app on realistic sample data. The release hardens the two things that made this risky before: it rehearses the whole plan before recording (so we don't publish broken videos) and it now supports our SPA/separate-frontend architecture and our real sign-in, including Sanctum, JWT, and SSO via a custom hook. Costs are bounded and small — rehearsal is free, page inspection is capped at three looks per video at roughly a cent each, and failures consume a fixed repair budget. Net: faster time-to-video per release, no vendor seat licenses for basic walkthroughs, and demos that track the product instead of going stale.

To engineering: This is a low-ceremony integration. Without VIDEO_DEMO_FRONTEND_URL nothing changes in behavior. The recorder uses signed links that only exist while the studio is enabled, hides secrets when it inspects a page, injects a signed header so frontend API calls hit the video's sample database with no CORS changes, and mints short-lived tokens in the video's own database (Sanctum tokens expire after an hour and expired ones are cleaned up). Two behaviors to be aware of: a 4xx on a mutating request now fails that step and hands the plan back to the AI for repair — GETs, Precognition validation, broadcasting auth, and guest 401s are deliberately exempt — and VIDEO_DEMO_REHEARSE=false disables the rehearsal pass if you need the old, faster path. The v0.18.0 fix also means role+label targeting (e.g. a "Location" text box) now resolves to the correct element instead of the first of that role, which should remove a class of flaky typing steps.