Overlook Laravel Package

Product Decisions This Supports

• Dashboard information architecture. Overlook answers a decision every Filament-based admin panel faces: "what does the landing page show?" Instead of a blank dashboard or a hand-built widget, it renders every registered resource as a count tile. That gives you a defensible default — the index of your domain model is the dashboard — without a design sprint.
• Build vs. buy on an "at-a-glance" summary. A PM can scope this as roughly a half-day of engineering (composer require, custom theme @source line, panel provider registration) versus 3–5 days to build and maintain an equivalent widget. That math usually resolves in favor of buy.
• Onboarding and wayfinding bets. Counts per resource are the cheapest possible signal for new internal users ("here's what exists, here's how much of it"). This supports a self-serve onboarding hypothesis you can test before investing in guided tours or a help center.
• Workload/backlog prioritization. Exposing per-resource volume — especially with includes() narrowed to the 6–8 resources that represent active work, and filters like withoutTrashed() and custom getOverlookWidgetQuery() (e.g., where('status','=','PENDING')) — turns the widget into a light operational queue view. That's a product decision about which numbers leaders see first, and it's configurable per panel rather than per-codebase.
• Multi-panel / multi-audience rollouts. Because includes/excludes, icon mapping, sort order, abbreviation, and responsive columns are all plugin-level config, you can ship different overviews for an ops panel vs. an admin panel without branching logic. Useful when a roadmap item is "tailor the console per persona."
• Scope containment for a v1. It deliberately does not do charts, time series, or KPIs. A PM can slot it in as a v1 and keep "real analytics" as a separately-scoped roadmap item, which keeps the launch small and reversible.
• Platform upgrade planning. Documented version matrix (3.x→Filament 4, 4.x→Filament 4 & 5) makes this a dependency you can reason about during a Filament upgrade, not a blocker you discover mid-migration.

When to Consider This Package

Adopt when all of the following hold:

• Your admin panel is Filament 4.x or 5.x on Laravel, and you already have (or are willing to add) a custom Filament theme — the install requires a theme CSS @source line, so a stock/no-theme setup is a friction point.
• Your value proposition for the dashboard is "what's in here and how much of it" — counts of resources, not trends, revenue, or funnel metrics.
• You have tens of thousands of records at most, or slow-moving tables. The widget issues a count per displayed resource on dashboard load; on very large or write-heavy tables that's a latency and database-load concern you'd need to verify with your own data.
• A single-maintainer, MIT, ~190-star plugin is an acceptable supply-chain risk. Low dependents (0) means a small community blast radius if the maintainer stops; the upside is a small, readable, low-magic codebase you could fork or vendor.
• You need presentation-level configurability only — order, icons, columns, abbreviations. There's no evidence of role/permission-based visibility per tile, so if "ops sees these six, finance sees those four" requires ACL, you're building on top.

Look elsewhere (or build) when:

• You need analytics: trends over time, period comparisons, charts, cohort or funnel views. This is a count snapshot, not a metrics layer.
• Your dashboard is the product rather than a convenience, or you need per-user personalization, saved views, or drill-down interactions.
• You're not on Filament (Nova, custom Blade, Inertia) — the entire value is panel integration.
• You need strict accessibility, i18n, or test-coverage guarantees; a small widget plugin typically doesn't carry those commitments, so budget for your own audit if those are release gates.
• Counts must be authorization-aware in a complex way (multi-tenant scoping beyond what getEloquentQuery() already provides) — verify that the resource query scoping matches your tenancy model before committing, and be prepared to implement the customization contract per resource.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: Overlook gives our admin panel a real homepage in about an afternoon of work. It's a free, MIT-licensed plugin for our existing Filament framework that lists every section of the console with a live count of what's in it — orders, customers, tickets, whatever we register — with configurable ordering, icons, and layout. It replaces either a blank dashboard or a bespoke widget we'd otherwise build and maintain ourselves. Risk is low and reversible: it's a single Composer dependency behind a config block, so removing it is a one-line change.

For engineering — the honest version: composer require awcodes/overlook, add the plugin and OverlookWidget to the panel provider, and add the vendor @source glob to our theme CSS. Configuration lives in one OverlookPlugin::make() chain: sort(), columns() (responsive breakpoints), includes()/excludes() (mutually exclusive), alphabetical(), abbreviateCount(), tooltips(), withoutTrashed(), and icons() keyed by resource class. Per-resource behavior goes through the CustomizeOverlookWidget contract plus the HandlesOverlookWidgetCustomization trait, overriding getOverlookWidgetQuery() and getOverlookWidgetTitle().

Three things to validate before we merge:

1. Query cost. One count() per visible resource on every dashboard load. Confirm it holds on our largest tables; if not, restrict via includes() to a curated set.
2. Tenancy/scoping. Confirm resource getEloquentQuery() already applies our tenant and policy scoping — the widget inherits it, so it's not a new hole, but it's worth a look.
3. Upgrade cadence. Version 4.x supports both Filament 4 and 5 on one line, which de-risks our next framework bump. Track the repo's release activity alongside our Filament upgrade ticket.

What we are explicitly not buying: analytics, charts, or time-series reporting. If a stakeholder asks for trends, that's a separate roadmap item — don't let it get smuggled into this ticket.