Pmk2 Stats Ui Bundle Laravel Package

Product Decisions This Supports

First, a framing correction that matters for any decision: despite being catalogued as a "Laravel/PHP package," teltek/pmk2-stats-ui-bundle is a Symfony bundle for PuMuKIT 2.x (Teltek's open-source video management platform). It is not a Laravel package and cannot be composer require-d into a Laravel app without a rewrite of the integration layer. Any roadmap decision should treat it as a domain-specific plugin, not a reusable analytics library.

Where it can genuinely inform product work:

• Feature-parity benchmark for a video/VMS roadmap. If you are scoping "usage analytics" for a media platform, this bundle is a working reference for the minimum viable stats UI: view counts, consumption trends, per-object/per-series reporting. Use it to calibrate scope, not as a dependency.
• Build vs. buy signal for analytics modules. Its existence — and its low signal (2 stars, 0 dependents, last release Jan 2022) — is evidence that bundled, in-app stats screens are a commodity feature that decays unless actively maintained. The build/buy conclusion leans toward buy or embed a dedicated analytics layer (Metabase, Grafana, Matomo/Plausible, Looker Studio) rather than hand-rolling UI inside the app.
• Prioritization input for editorial/stakeholder reporting. In its native PuMuKIT context it supports decisions like: which content to invest in, catalog curation, and proving engagement to academic/enterprise stakeholders. If your users are asking for "how many views did this series get," that is a real, cheap-to-satisfy request — but it should be satisfied by an analytics tool, not this bundle, in a Laravel stack.
• Use-case validation, not architecture. Treat it as a use-case card, not a component: "internal stats dashboard for a video platform's content team." That use case is worth a roadmap slot; this specific code is not worth an integration.

Net PM read: it supports understanding the problem space and framing a build-vs-buy argument. It supports no concrete Laravel feature delivery.

When to Consider This Package

Adopt only if all of the following hold:

• You are running PuMuKIT 2.x on a compatible Symfony/PHP version — this is the primary and essentially only valid context.
• You need lightweight, in-app usage metrics (views/consumption) and explicitly do not need warehouse export, multi-tenant isolation, SSO-scoped dashboards, or advanced segmentation.
• You accept that you will own and maintain it: last release was 2022-01-04, the repo has 2 stars and 0 dependents, and the catalog score is 0.04. Plan for a fork and a maintenance budget, not a passive dependency.
• The alternative — building the screen yourself or wiring a BI tool — is materially more expensive for this specific platform, which is rarely true.

Look elsewhere when:

• You are on Laravel. This is a Symfony bundle tied to PuMuKIT's domain model (multimedia objects, series, playlists). Integration cost is a rewrite, not a config change.
• You need a maintained, security-supported dependency. A 2022-vintage release with no dependents is an unpatched surface; expect to own CVEs and PHP-version drift yourself.
• You need real analytics. Laravel Analytics, Plausible/Matomo, Metabase, Grafana, or a custom Filament/Nova dashboard will out-deliver this on every axis except "already written for PuMuKIT."
• You need a community or support contract. Two stars and zero dependents means no ecosystem, no Stack Overflow answers, no upstream momentum. Your team is the community.

Decision rule: if the answer to "are we a PuMuKIT shop?" is anything other than an immediate yes, stop evaluating this package.

How to Pitch It (Stakeholders)

To executives (30 seconds): This is a small, single-purpose UI add-on for one specific video platform (PuMuKIT), not a general analytics library for our Laravel product. It is free to use but effectively unmaintained — last release January 2022, two GitHub stars, no downstream users. Recommendation: do not adopt as a strategic dependency. The real decision it informs is build vs. buy for analytics, and the evidence points to buying/embedding a dedicated tool rather than maintaining bespoke stats screens. Risk is low (we'd simply not use it); upside is also low.

To engineering (the honest version): It's a Symfony bundle, not Laravel — catalog metadata is wrong. It ships a stats UI over PuMuKIT's own data model, so there's no reusable API to lift. If we want the capability, budget it as a small in-house dashboard against our own models (or a BI tool pointed at the DB), which will be faster to build than porting this, and won't leave us owning an abandoned 2022 codebase.

Positioning line for the roadmap review: "We evaluated pmk2-stats-ui-bundle for analytics. It's a platform-specific, unmaintained Symfony bundle with no adoption — not viable for our stack. It does confirm demand for in-app usage reporting; we recommend satisfying that with [BI tool / lightweight custom dashboard] at roughly [X] engineering days."

Bottom line: a reference artifact, not a dependency. Spend ten minutes reading it for scope calibration; spend zero sprints integrating it.