Bi Laravel Package

Product Decisions This Supports

• Build vs. buy for internal analytics. If your product roadmap includes an admin-side "insights" surface — KPI tiles, cohort charts, revenue dashboards — this package is a candidate to replace 4–8 weeks of in-house chart/widget plumbing with a configurable dashboard manager. The buy case only holds if you are already a Laravel shop; the moment you leave that stack, the value collapses.
• Scope decisions on reporting features. Because dashboards are defined as block classes and resolved server-side, a PM can defer "custom report builder" or "let customers compose their own dashboards" and instead ship a fixed set of curated dashboards, keeping the query layer under engineering control rather than exposing it to end users.
• Roadmap sequencing for a BI surface. The package gives you filters, widgets, and boot-payload reducers out of the box; that means the first release can be "v1: five curated dashboards for internal teams" rather than "v1: a BI platform." It buys you a cheap proof of demand before committing headcount.
• Data-access product decisions. Any adoption forces a conversation about which tables the dashboard layer is allowed to read, whether queries are scoped per tenant, and whether the BI routes sit behind the same authorization as the rest of the admin. That is a product/security decision, not just an engineering one, and it should be made before the pilot, not after.
• Vendor and fork strategy. With a single-maintainer signal, near-zero public adoption, and an ecosystem coupling to luminix/frontend, the realistic decision is not "adopt vs. ignore" but "pilot, vendor, and budget for a fork." A PM should treat the package as an internal starting point, not a dependency you can lean on for years.
• Localization and documentation decisions. Human-facing docs and the readme ship in Portuguese, while the agent-facing skill ships in English. If your team is English-first, the real cost is not licensing but onboarding and support; that cost belongs in the build-vs-buy math.

When to Consider This Package

• You are on Laravel 11–13 / PHP 8.2–8.5 and your admin surface is already Laravel-rendered. The package is explicitly tested against that matrix, so version drift outside it is your problem to validate.
• You are already in the Luminix ecosystem, or are willing to take luminix/frontend as a dependency and accept its static reducer registry (and the associated test-isolation discipline around BootService::flushReducers()).
• The dashboards are internal and curated, not customer-facing self-service. Fixed block classes with a resolver are a good fit for "here are the ten numbers the ops team checks daily."
• You can afford a timeboxed spike and a maintained fork. Someone on the team should own upgrades, because upstream adoption signals (0 stars, 0 dependents) mean you will not get incidental bug-fixes from a crowd.
• You need self-hosted, no-per-seat BI. Avoiding a SaaS BI licence is a legitimate driver; the trade is paying in engineering ownership instead of subscription.

Look elsewhere when: you need vendor SLAs or a support contract; your team is not Laravel-native; your docs/onboarding must be English-first; you need a genuine ad-hoc query builder for end users; you have multi-tenant query-isolation requirements that a resolver cannot express safely; or you expect to still be running this in five years with no dedicated maintainer. In those cases, an established BI tool or a thin in-house charting layer is the lower-risk choice.

How to Pitch It (Stakeholders)

For executives: this is a self-hosted dashboard layer for our existing Laravel admin, not a new platform. It gives us a credible internal-BI surface in weeks rather than a quarter, with no per-seat licence and no data leaving our infrastructure. The honest caveat is maturity: it is a young, low-adoption package with a very small maintainer base, so we should treat it as a head start we own — pilot it behind our own auth, and budget a modest amount of engineering time to keep it patched or fork it if upstream stalls. If we need customer-facing analytics or enterprise support, we should not use this.

For engineering: the package ships a dashboard manager with block/widget classes, server-side resolution, and a boot payload integrated with luminix/frontend reducers. Two things to flag: DashboardResolver runs on every boot payload, so it must stay cheap and non-throwing, and any test that boots the service provider must flush static reducers in teardown or leak state across the suite. Docs for consumers exist as a published skill (vendor:publish --tag=luminix-skill), which means agent-assisted development is a first-class path — but the human docs are Portuguese, so plan for an internal English summary. The test harness is Dockerised (php-composer:8.3-imagick), so CI needs that image or an equivalent.

Bottom line: worth a two-week spike against one real dashboard; not worth a multi-year dependency commitment without a named owner and a fork budget.