Product Decisions This Supports
- Build vs. buy for internal presentation surfaces. SlideWire converts "we need a place to host internal decks" from a bespoke frontend project into a
composer require plus a deck template. The decision it enables is narrow and real: if the need is internal enablement, onboarding, architecture walkthroughs, release/roadmap communication, or authenticated product demos inside an existing Laravel app, this is a buy (adopt) rather than a build.
- Closing the "stale collateral" loop. The genuinely differentiated product capability is that a deck can read from the application itself — current pricing, feature flags, roadmap status, live metrics — instead of a manually refreshed screenshot. That reframes the roadmap item from "make a better deck tool" to "eliminate a class of deck-drift defects," which is a measurable, PM-owned outcome (fewer refresh requests, fresher onboarding material).
- Authoring convention as the deliverable. The package ships the commodity mechanics (keyboard/click/swipe/hash navigation, horizontal slides with nested vertical groups, fragments, transitions, auto-animate, progress, fullscreen, theme presets, Phiki highlighting, diagrams, Reveal-style backgrounds, auto-slide timers with config → deck → slide precedence). The PM-level artifact to standardize is therefore a reusable deck template — one route convention, one theme, one component vocabulary, many decks — not the package internals. Since v1.4.0, Markdown and composed decks widen the authoring audience beyond engineers.
- Scoping which content types are in and out. This supports an explicit portfolio decision: internal and semi-public decks behind auth are in scope; external, SEO-critical, offline, or PDF/PPTX-handoff decks are out of scope without a compensating workflow. That boundary should be written down before the pilot, not discovered at the first stakeholder request for an export.
- Roadmap gating on platform strategy. Adoption is only cheap where Laravel 10+/Livewire 3.x is already the standard. If Livewire is incidental rather than strategic, adopting SlideWire quietly promotes it to a platform dependency for presentation content — a decision worth making deliberately, not by accident.
- Pilot success metrics to define up front. Authoring hours saved per deck, time-to-first-publish for a new deck, number of decks whose data is live-bound versus manually refreshed, and route-level engagement on internal decks. These are the numbers that justify (or kill) broader standardization.
When to Consider This Package
- Strong fit: an existing Laravel + Livewire 3.x application; decks can live behind the app's existing auth, middleware, layouts, and asset pipeline; the brand system is Tailwind-based; the primary audience is internal (enablement, onboarding, release/roadmap, demos); and someone is willing to own upgrades and the deck template.
- Reasonable fit with a theming spike first: brand-exact layouts are required. Ship theme presets and typography controls, but plan for custom Blade components and CSS overrides, plus the non-obvious build step —
@source entries in resources/css/app.css pointing at vendor/wendelladriel/slidewire/resources/views/**/*.blade.php and src/**/*.php. Without them, components render with missing styles despite correct markup. Treat this as an integration checklist item, not tribal knowledge.
- Start with the pain, not a demo. Port one deck that is currently causing pain (stale onboarding material, a sales deck with hand-refreshed metrics, a roadmap deck drifting from the tracker) using
php artisan make:slidewire, run it in parallel with the incumbent for one review cycle, then redirect the internal link.
- Look elsewhere — hard requirements: PDF/PPTX export or offline delivery (output is HTML/JS only); SCORM/LMS integration; formal accessibility compliance or ARIA guarantees (none documented, and Livewire requires JavaScript); SEO-critical public pages (no built-in SEO metadata); localization programs.
- Look elsewhere — poor stack fit: Inertia/Vue/React-fronted apps, Livewire 2.x, or legacy Laravel. Here the cost shifts from package setup to platform migration, which is almost never justified by presentations.
- Look elsewhere — governance constraints: if single-maintainer risk is unacceptable and no one will own vendoring, pinning, or a replacement path. Also confirm the actual installable version on Packagist during dependency audit; published release metadata lists a date beyond the present, so pin explicitly rather than trusting "latest."
- Look elsewhere — untrusted authoring: decks are trusted Blade/Livewire code, i.e., a template-execution surface. If non-engineers must author without engineering review, this is an XSS and code-execution risk, not a workflow convenience.
- Budget the hidden CI and ops cost: browser tests pull in Playwright plus Chromium (
npx playwright install chromium), and php artisan config:cache must be an explicit test case given theme/typography DTO serialization (fixed in v1.3.2). Pin versions and read release notes — v1.4.x is still moving feature surface.
How to Pitch It (Stakeholders)
To executives (one paragraph): SlideWire lets us publish internal presentations directly inside the product we already run, so decks can show real, current numbers instead of last quarter's screenshots. It is a small, MIT-licensed package that plugs into our existing Laravel stack — no new platform, no new vendor contract, no separate frontend team. The proposal is a narrow pilot on one deck that is currently causing pain, measured on authoring time saved and deck freshness, with a go/no-go before any broader rollout. It is deliberately not a replacement for Google Slides or Keynote where we need export, offline delivery, or pixel-perfect brand control; those stay on existing tools.
To engineering (the ask): add the package, scaffold one deck with make:slidewire, register a route behind existing auth, and wire the Tailwind @source entries. Keep slide files thin — Blade or Markdown composing first-party components, data access through explicit bounded queries, no application logic in slides. Pin the version, add config:cache and a Playwright/Chromium step to CI, and name an owner for upgrades. Expect to build a deck template and theme layer on top; the package supplies navigation and presentation mechanics, not our brand.
Framing the risk honestly: 142 stars, zero dependents, a young 1.x line, and a single primary maintainer mean this is a dependency to isolate, not a platform bet. The navigation layer is coupled to Livewire, so replacing it later means replacing that layer — content survives if we keep it thin in Blade/Markdown. Accessibility and SEO guarantees are undocumented, so nothing external or compliance-bound goes through it. And the package's own quality gates (composer lint, composer test, composer test:browser) validate the package, not our deck template or data bindings — that verification is on us.