Dashboard Module Laravel Package

Product Decisions This Supports

• Build vs. buy on the admin console. If the product lives on the Streams Platform, this package supplies the dashboard shell — dashboard creation, multi-column widget layout, persisted configurations, and addon-registered widgets — so the decision shifts from "build a dashboard framework" to "register the widgets we actually need." That is weeks of scaffolding removed from an admin v1 scope.
• Roadmap sequencing for extensibility. Because widgets are addons rather than hardcoded panels, this supports a phased plan: ship a fixed set of first-party widgets at launch, then expose third-party/customer-authored widgets later without re-architecting the dashboard.
• Feature decision: configurable vs. curated dashboards. The package assumes user-composed dashboards. Adopting it is an implicit product commitment to letting admins arrange their own views — decide that early, because it drives support load, permission design, and empty-state UX.
• Platform lock-in is the real decision. This is a module, not a standalone library; it only runs inside Streams. Choosing it is a decision about the CMS/platform bet, not about a dashboard component — treat it as a platform-level commit and evaluate it alongside the rest of the Streams addon set.
• Buy-side fallback framing. Use it as a scoped reference implementation: even if we don't adopt, the widget-registration and layout-persistence model is a cheap template for a Laravel + Filament/Livewire build.

When to Consider This Package

Consider it when:

• The application is already on Streams Platform / PyroCMS (or is being scoped there), and the admin surface needs dashboards quickly.
• Requirements are modest and internal-facing: ops console, content team landing page, KPI tiles, per-role starting dashboards.
• The team is small and Laravel-fluent, and speed to first release outweighs long-term dependency hygiene.
• MIT licensing and forkability matter more than vendor support — permissive, small, and readable enough to vendor into the repo.

Look elsewhere when:

• The app is a standalone Laravel product not on Streams. There is no meaningful integration path; the fit is effectively zero.
• You need an actively maintained dependency. Three stars and zero dependents means near-zero community surface: no ecosystem answers, no third-party security review, and an unproven bus factor.
• The dashboard is customer-facing or revenue-bearing. For that, prefer Laravel Nova, Filament widgets, or a purpose-built Livewire/Inertia dashboard with predictable upgrade paths.
• Requirements are BI-grade — arbitrary charting, scheduled reporting, drill-down — where Metabase/Superset or a warehouse-backed tool is the cheaper answer than extending a CMS widget system.
• Compliance or long-lived support obligations apply; a low-adoption addon will land poorly in a dependency review.
• The team needs modern front-end ergonomics (SPA, real-time updates); the module reflects the platform's server-rendered conventions.

How to Pitch It (Stakeholders)

To executives: A small, MIT-licensed module that gives us the composition layer of an admin dashboard — layout, persistence, widget registration — for free, provided we are on the Streams Platform. The value is schedule, not license cost. The risk is maturity: adoption is negligible, so we should budget for forking and owning it rather than expecting upstream fixes. Recommendation: fund it as an accelerator inside the platform bet, not as a strategic dependency.

To engineering: It's an addon, not a library — the integration surface is Streams itself, which is the bulk of the work. Scope the evaluation as "do we adopt Streams, and does this module cover the dashboard requirement?" rather than a standalone trial. Plan to vendor or fork from day one: pin the version, read the source, and assume no upstream support. If we're not on Streams, close the evaluation and spend the same effort on Filament widgets.