Radar Laravel Package

Product Decisions This Supports

• Build vs. buy for an embedded dashboard. Radar ships a ready-made UI as a Laravel package rather than a hosted SaaS product. For a PM, the decision this unlocks is: do we spend 1–2 sprints of engineering on an in-house dashboard/insight surface, or adopt a package, keep our engineers on core roadmap work, and accept pre-1.0 dependency risk.
• Where the surface lives. Because the dashboard is shipped as a publishable package (a dashboard layout is a Blade view, and v0.3.1 is explicitly a layout rename), Radar is designed to be themed and embedded inside our own app and auth boundary. That supports decisions about whether this is an internal-only ops tool, an admin-only view, or something customer-facing.
• Roadmap sequencing and upgrade budget. At 0.x, minor bumps can carry breaking changes. v0.3.1 (jumping from v0.2.3, so it includes the unreleased v0.3.0 work) is a good reminder to plan upgrade work as recurring roadmap overhead — a half-day per bump — rather than a one-off setup task.
• White-labeling / branding scope. If we intend to override or restyle published views, we are coupling our fork to internal view names. That choice is a product decision (brand consistency vs. cheap upgrade path) and should be made deliberately, not by accident.
• Use cases to validate in the pilot: internal operational visibility, support triage of user-reported issues, and giving non-engineering stakeholders a read-only window into system state without building bespoke reporting.

When to Consider This Package

Consider adopting when:

• The application is a Laravel app on a currently supported version, and the team is already comfortable with Composer-installed, vendor-published UI packages (config + view publishing, standard service provider wiring).
• The need is well-defined and mostly presentational — an internal or admin dashboard — and "good enough, ours, and cheap" beats "bespoke and perfect."
• Engineering can absorb 0.x churn: version pinned exactly (0.3.1, not ^0.3), changelog reviewed on each bump, and a named owner for upgrades.
• The deploy pipeline can reliably clear compiled views. v0.3.1 exists because a layout rename left stale compiled views behind — this is a deployment-hygiene dependency, not just a code dependency. If clearing view caches is a manual, forgotten step in your release process, expect avoidable "the dashboard looks broken" tickets.
• Exposure can sit behind existing authorization. Treat the dashboard as an admin surface and gate it.

Look elsewhere when:

• You need a stability commitment, an SLA, or vendor support. 0.x from a single maintainer is a bet on a person, not a contract.
• You plan to heavily override or fork the published layout. v0.3.1 renames a layout view specifically to fix a caching problem; renames like this are routine pre-1.0 and will silently break forks that reference the old name. If deep customization is core to your product, build it.
• The dashboard would be customer-facing or multi-tenant in a way that makes visual or behavioral regressions revenue-affecting.
• Your team has no Laravel view/Blade conventions experience — you'll inherit the upgrade work without the ability to debug it.
• A first-party or heavily adopted alternative already covers the need; a 0.x package is not worth adopting for a marginal gain over something you already operate.

How to Pitch It (Stakeholders)

For executives (one paragraph): Radar is a small, free, open-source Laravel package that gives us a dashboard surface we would otherwise have to build and maintain ourselves. The trade is straightforward: we avoid several weeks of engineering on a non-differentiating internal tool, and in exchange we accept some dependency risk — it's pre-1.0, maintained by a single author, and version bumps can occasionally require a small code change. I recommend a time-boxed pilot behind our existing admin authorization, with the version pinned and an owner assigned for upgrades, before we commit to it as a permanent part of the stack.

For engineering (the ask): Spike integration in a branch — Composer install, publish config and views, wire the dashboard route behind admin middleware, confirm it renders under our production-like cache settings. Specific risks to confirm: (1) the v0.3.1 layout rename means published views must be re-published or manually reconciled on upgrade, and any local override of the old layout name will break; (2) stale compiled views were the actual bug being fixed, so our deploy runbook must include a view-cache clear on release; (3) we pin to an exact version and review the changelog per bump, since 0.x minors carry no compatibility promise. Deliverable is a go/no-go with an estimate of ongoing upgrade cost, not a production rollout.