Laravel Package Quick Demo Laravel Package

Product Decisions This Supports

• Whether "time-to-first-demo" is a growth lever worth investing in. This package exists to collapse the "read the README, copy files, edit .env, get stuck on a DB error" path into a single command: php artisan quick-demo:install blog-demo → open /quick-demo/blog-demo. That directly informs whether demo/onboarding experience gets roadmap capacity or stays ad-hoc.
• Feature vs. enablement budgeting. It forces an explicit tradeoff between shipping new package features and shipping the tooling that makes existing features discoverable and trialable. A PM can use the demo-install success rate as the counter-metric to feature velocity.
• Build vs. buy for developer-experience tooling. The realistic alternative is hand-rolled shell scripts, a Docker Compose sandbox, or a Pest/Dusk harness per package. Building that internally is ~1–2 sprints plus permanent maintenance of edge cases the package already encodes (isolated SQLite connection per demo, prefixed routes/views/assets, forced-overwrite protection, lifecycle hooks). Buying is a single ^0.1 dependency — but see the adoption risk below.
• Standardization decisions across a package portfolio. If we publish multiple Laravel packages (or a commercial suite), this defines a convention: package-scoped demo keys (blog-demo, not demo), package-scoped DB names, demo_-prefixed tables, /quick-demo/{key} route mounting, public/vendor/quick-demos/... assets. PM owns whether that convention becomes a published standard or stays a suggestion.
• Demo isolation policy. The hard rules — never mutate host .env, config/database.php, or routes/web.php; never seed the default connection — are product-grade constraints. This gives us a defensible answer to "will your demo pollute my app?" which is the #1 objection in package trials.
• Concrete use cases to prioritize: prospect/trial sandbox, interactive docs, conference and sales-call demos, support-ticket reproduction ("run quick-demo:install and send us the URL"), QA bug reports, internal onboarding of new engineers, and marketplace/listing evaluation pages.
• Roadmap placement and metrics. Enables a measurable activation funnel: demo listed → installed → routes hit → session length. Instrument quick-demo:list / install command usage and tie it to package composer require conversion and support-ticket volume.
• Scope boundary decision: local demo only. This is a developer-machine installer, not a multi-tenant sandbox or hosted demo provisioner. Knowing that up front prevents an expensive scope creep request later.

When to Consider This Package

Consider adopting when:

• You maintain two or more Laravel packages (or a suite with shared demo needs) and each currently needs bespoke setup instructions.
• Package adoption is a business input — paid packages, OSS with a growth goal, or a partner/integrator ecosystem — not just an internal utility.
• Your demo content is seedable and self-contained: a few tables, a handful of seeded rows, Blade views, static assets. The examples/ structure maps cleanly onto that.
• You want reproducible demos in CI or on a clean laptop, and you value the "no changes to the host app" guarantee as a support-deflection tool.
• Your team is on a modern Laravel and is comfortable registering a DemoDefinition in a service provider and following the QuickDemo::connectionName() pattern in migrations, seeders, and models.
• You can pin the version, wrap it thinly, and vendor-fork if needed. At 1 star, 0 dependents, a 0.1.x line and effectively single-maintainer risk, adoption should be a timeboxed pilot, not a platform bet.

Look elsewhere (or wait) when:

• You have one package and a demo that already works — the abstraction cost exceeds the benefit.
• You need hosted, multi-user, or ephemeral cloud demos (sales sandboxes, trial tenants, per-prospect URLs). This is a local installer; you want a provisioning service or container platform.
• Your demo requires real application data, external APIs, queue workers, or non-SQLite services — the isolated-SQLite model fights you, and lifecycle hooks become a workaround pile.
• You need stability guarantees: versioned LTS, a security-response process, an SLA, or a broad install base you can lean on when something breaks. Right now you'd be an early adopter subsidizing maturity.
• Your stack is not Laravel/PHP (docs sites, JS SDK demos, mobile).
• Your compliance posture forbids adding an unvetted third-party dependency to shipped packages — in that case, copy the pattern (isolated DB, prefixed routes, no host-file mutation) into an internal package instead of depending on this one.

How to Pitch It (Stakeholders)

For executives (one paragraph): Today, trying one of our Laravel packages means a page of manual setup — editing .env, wiring a database, copying files — and most evaluators quit before they see anything work. This package turns that into a single command and a URL. It's a small, scoped dependency that makes our packages tryable in about two minutes, which is the cheapest lever we have on adoption, pre-sales demo time, and support load. The cost is low and reversible; the main caveat is that the package is very young, so I recommend a timeboxed pilot on one package before standardizing.

For engineering (the substance):

• What it does: registers a DemoDefinition in the package's service provider (key, name, DB name, stub, migrations, seeders, routes, views, assets, storage, config, optional hooks). Users run php artisan quick-demo:list / show / install <key> --fresh --force. It provisions an isolated SQLite file under database/quick-demos/, registers a per-demo connection, runs migrations and seeders against that connection only, and mounts routes at /quick-demo/{key} with quick-demo.{key}. name prefixes.
• Safety properties we care about: it explicitly does not touch the host's .env, config/database.php, or routes/web.php; it does not create or seed tables on the default connection; routes, views, assets, storage, and config are all namespaced under the demo key; existing generated files are never overwritten without --force. That is exactly the blast-radius control we'd otherwise have to build and audit ourselves.
• Effort and risk: registration is a few lines per package plus an examples/ folder; migrations, seeders, and models need one line each (QuickDemo::connectionName(...)) to stay on the demo connection. The package's own agent guide functions as an implementation checklist and validation runbook, which lowers integration risk and review time.
• Maturity caveat, stated plainly: 1 star, 0 dependents, 0.1.x. Treat it as an early dependency: pin the version, isolate it behind our own thin DemoDefinition helper so a swap is cheap, and be prepared to fork. If it stalls, the pattern is small enough to internalize.
• Recommendation: run a 2–3 day pilot on the package with the weakest trial experience, measure install success and time-to-first-page, then decide on portfolio-wide adoption. Ship it as a dev-only dependency so nothing reaches production consumers.