Widget Laravel Package

Product Decisions This Supports

• Internal dashboard: build vs. buy (shell layer). orchid/widget is the "card primitive" for an admin surface — KPI tiles, counters, activity feeds, mini-tables, status lights — placed in rows and columns and registered per screen. When a roadmap item says "ops needs a dashboard," this answers whether we hand-roll a dashboard shell or assemble one from existing primitives. It is a shell-and-layout decision, not a charting or analytics decision.
• Deferring a BI tool purchase. A permission-aware widget grid with async loading and periodic refresh absorbs the first two to three quarters of "we need a metrics dashboard" requests. That postpones Looker/Metabase/Retool-class spend — and, more importantly, postpones the procurement and data-modeling work those tools imply. This is the strongest budget argument in favor of the package and the one to lead with.
• Roadmap sequencing for ops-facing features. Near-real-time status boards (queue health, order volume, failed jobs) get cheap once widgets can load asynchronously. Scheduling, alerting, and drill-down then become explicit follow-on roadmap items rather than smuggled into the first dashboard ticket.
• Standardization of internal UI. If the org already runs Orchid, this decides whether new dashboards are widget-based (consistent, permission-aware, disposable) or bespoke Blade pages (drift, duplicated layout code, inconsistent authorization). Pick one and encode it in the team's definition of done.
• Internal tooling vs. product investment. Adopting it is a bet that internal dashboards should be assembled from off-the-shelf primitives rather than designed. The trade is explicit: engineering days returned to the product surface, in exchange for admin UI that looks like everyone else's admin UI.
• Read the score correctly. Zero stars, zero dependents, and a 0.3 score describe standalone adoption, not fitness. This is a split-out satellite of orchid/platform, consumed transitively; its real adoption is the platform's adoption. Do not put this row into a build-vs-buy scorecard as an independent market signal — it will produce a false negative. The PM-relevant question is "does our team already run Orchid," and the answer is binary.

When to Consider This Package

Consider it only when all of these hold:

• Orchid Platform is already committed in a Laravel app you own. The package is not independently useful; adopting it means adopting the platform — its migrations, assets, middleware, and auth model.
• Your needs are card-shaped. Single-metric tiles, counts, short lists, status lights, and lightweight charts via a companion JS library. Not multi-dimensional exploration or ad-hoc querying.
• You want placement and refresh without layout code. Per-widget row/column registration and auto-refresh are the actual value; if you would build those anyway, the package buys you little.
• You are a PHP/Laravel shop comfortable with Blade-templated admin UI and Orchid's conventions, and you will not fight them.
• MIT licensing and a single-maintainer ecosystem are acceptable for a non-differentiating internal surface, with a named owner and a documented fork path.
• The data is internal. Authenticated staff, bounded concurrency, tolerance for a few seconds of staleness.

Look elsewhere when:

• You are on Filament, Nova, Backpack, or a Livewire-first stack. The abstraction is Orchid-specific and does not port; porting cost exceeds rewriting.
• You need push/websocket real-time or sub-second freshness. Polling is the model.
• You need a real analytics or query layer. Pair with a BI tool or a dedicated charting package; do not treat this as the analytics engine.
• The surface is customer-facing. Orchid is an admin framework. Widgets implicitly protected by /admin middleware become reachable if rendered on public routes — both a design liability and a data-exposure risk.
• You require strong maintenance and security signals on the dependency itself. Then evaluate the parent orchid/platform repo's release cadence and issue response, and expect breaking changes across Orchid majors.
• Someone proposes adding orchid/platform to a frontend app just to unlock widgets. That inverts the dependency direction and imports an admin panel into a surface that never needed one.

Also flag before any spike: the repo name (tabuna/widget) and the package name (orchid/widget) do not match. Confirm canonical source and provenance — that is a supply-chain question a PM should raise, not leave entirely to engineering.

How to Pitch It (Stakeholders)

To executives (one paragraph). We can stand up internal dashboards — KPI tiles, activity feeds, ops status boards — on the Laravel stack we already run, at zero license cost under MIT, using the widget layer of a mature admin framework instead of buying a BI tool or building a dashboard shell from scratch. The return is time-to-first-dashboard and deferred tooling spend, not differentiated capability. The risk is concentration: this sits in a single-maintainer ecosystem and is a satellite of the parent platform, so treat it as internal, non-critical infrastructure — pin versions, name an owner, and keep a documented exit path. Success looks like dashboards shipped in days rather than sprints, dashboard requests absorbed without new tooling spend, and bespoke back-office pages retired in favor of widgets.

To engineering (the honest version). This is a satellite package of orchid/platform, not a standalone library — zero stars and zero dependents are artifacts of a monorepo split, so evaluate the parent project's health, changelog, and upgrade path, not this repo's stats. Mechanically it is a composer require plus auto-discovery; structurally it is a contract with Orchid's internal rendering API, which has moved across majors. Assume we own it: pin orchid/platform explicitly, pin the widget package to a commit SHA rather than a floating constraint, and verify the render path survives config:cache and route:cache. Treat widget handlers as production code — they execute on page load, so an unindexed aggregate per tile per refresh is a real, recurring cost. Mandate caching or precomputed aggregates and per-widget timeouts before we ship more than a handful of tiles. Re-audit authorization per widget for any context outside /admin; do not inherit the admin panel's guard. Add a smoke test that renders each widget and asserts non-empty output — that is our upgrade canary. Budget three to five engineer-days per Orchid major upgrade as a standing line item, and record the adoption rationale in an ADR so the next engineer does not silently inherit an orphan.

Default recommendation: if we already run Orchid, adopt the pattern and migrate one low-risk read-only widget first behind a feature flag. If we do not, reproduce the directive and rendering contract in-repo — a few hundred lines we own and test — rather than taking the dependency: same ergonomics, no supply-chain exposure, no admin panel dragged in behind a view primitive.