Zeus Laravel Package

Product Decisions This Supports

The core framing: this is a starter kit, not a dependency. lara-zeus/zeus is a runnable Laravel app pre-wired with the whole Zeus family (core, admin panel, forms, tables, and the Bolt CMS/blog module) on the TALL stack. That single fact determines which decisions it can and cannot inform: it answers "how fast can we get a credible admin surface in front of users?" — not "what component should we add to our existing product?"

• Build vs. buy vs. bootstrap for admin/back-office. The real fork is: fund 4–6 weeks of bespoke admin scaffolding, adopt Filament (or another admin suite) directly, or bootstrap from an opinionated kit that already encodes forms/tables/CRUD conventions. This is a time-to-first-demo decision to settle with a time-boxed spike, not an architecture debate.
• Sequencing an existing roadmap item. Forms + tables + CRUD + Bolt (posts, categories, tags) maps onto a roadmap entry most Laravel shops already have: internal CMS, marketing content back office, or a support-ops console. If that item is already slated, Zeus converts a sprint of plumbing into configuration work. If it isn't slated, do not invent a roadmap item to justify the tool — it's a solution looking for a problem.
• Drawing the internal-tooling boundary. Zeus's sweet spot is internal, CRUD-shaped, low-design-ownership surfaces. This supports a portfolio decision: run Zeus on internal ops/back-office (fast, cheap, churn-tolerant) and keep customer-facing product on a stack you fully own. Naming that line explicitly prevents the classic drift where an internal accelerator quietly becomes production-critical UI with no design-system owner and one upstream maintainer.
• Framework-currency scheduling. v4.0.0 is a compatibility release — a Laravel 13.x Shift plus two Tailwind PRs, no new capability. So it answers "when can we schedule the Laravel 12 → 13 move?" (the admin layer is now unblocked) and reframes that work as a coordinated, cross-functional upgrade project rather than a patch. Plan for roughly one such migration per Laravel major, because Zeus majors track Laravel majors.
• Upgrade cost budgeting, in design hours as well as engineering hours. Two of three v4 PRs are Tailwind-related — the highest-risk surface for anyone with customized published views or a non-standard asset pipeline. Budget design QA alongside engineering time and name "styles silently missing in the production build while dev looks correct" as a predicted failure mode in the plan, not a surprise in the retro.
• Platform-bet sizing — record the negative signal. 87 stars and zero dependents is a clear instruction: treat Zeus as an accelerator you can walk away from, not a platform bet. The metric is partly distorted (starter kits get cloned, not depended on), but the practical consequence stands — thin public troubleshooting corpus, few public bug reports, small safety net. That steers adoption toward contexts where exit is cheap.
• Vendor and exit-cost planning as a PM lever. Because the value is conventions rather than a dependency, your levers are contractual and architectural: insist output stays standard Blade/Livewire/Tailwind, insist Zeus abstractions never leak into domain code, and require a documented fallback (hand-rolled screens, or Filament) before the first screen ships.
• Deferred feature requests. v4 is scoped to compatibility, so pending feature asks become post-v4 items. Set that expectation now so the major bump isn't misread internally as a capability drop.

Concrete use cases this supports: internal admin panels, back-office CRUD, form- and table-heavy operational tooling, and a lightweight content/blog module for small-to-mid teams already on Laravel + Livewire + Tailwind.

When to Consider This Package

Consider it when:

• You're standing up a greenfield internal admin/back-office app on Laravel 13.x and want something runnable on day one. Strongest fit — with a starter kit, the value is the pre-wiring, and the cost of trying is a spike, not a migration.
• Your team is already standardized on Laravel + Livewire + Tailwind and wants scaffolding that matches, rather than introducing a JS SPA admin.
• The admin surface is internal and CRUD-shaped: records, forms, tables, simple dashboards, a lightweight CMS — not customer-facing or highly bespoke.
• You'll genuinely accept upstream styling and view decisions in exchange for speed. If design will veto package defaults in review, the speed argument evaporates and so does the case.
• You need a content/blog module now (Bolt: posts, categories, tags) instead of a bespoke content model.
• You're on or moving to Laravel 13.x — v4 is the supporting version; 3.1.7 and earlier are effectively frozen on older Laravel.
• You can absorb a major cadence tied to Laravel and Tailwind releases, and you have or will build a visual-QA habit for admin screens.

Look elsewhere when:

• You need a large ecosystem, plugin marketplace, commercial SLA, or enterprise support — go to Filament directly or a commercial suite. Zero dependents, low stars, and a single credited maintainer mean real key-person and bus-factor risk; confine Zeus to non-critical surfaces unless you fund support, a maintained fork, or a paid arrangement.
• You have heavily customized published views or a bespoke CSS pipeline. The v4 Tailwind refresh makes custom theming the dominant migration cost; a less opinionated kit or Filament itself will likely be cheaper over a multi-year horizon.
• You're brownfield. Do not install this into a live application — the kit wants to own layout, assets, and routing, so retrofitting is a framework migration disguised as a package install. Port the patterns (table/form class structure, panel-provider wiring) instead.
• The surface is customer-facing or design-critical, or you need guaranteed accessibility/compliance sign-off on the UI.
• You need stable, semantically versioned API guarantees. v4's changelog is three PR titles with no migration guide and no stated Tailwind major; semver is the only contract.
• You aren't on Laravel 13.x and can't move — you'd be adopting a frozen branch.

Non-negotiable adoption gates before committing: resolve the Filament question on day one (read composer.json and the panel provider — the vendor description and third-party summaries disagree on whether Zeus is Filament or an alternative to it, and that changes your entire dependency train). Pin exactly (4.0.x, not ^4.0). Strip Bolt early if you don't need the CMS surface. And define the kill criteria up front: if the asset build fights your pipeline or the form/table API makes you fight the framework, walk.

How to Pitch It (Stakeholders)

For executives — one paragraph: Zeus is a free, open-source Laravel starter kit that gives us a working admin/back-office panel in days instead of weeks, pre-built on a stack our team already uses (Laravel, Livewire, Tailwind). It carries no license cost and no lock-in: the output is standard Blade/Livewire, so we can walk away and hand-maintain any screen if the project stalls. The tradeoff is support risk — it's a small, single-maintainer project with a compatibility-driven release cadence rather than a supported commercial product. Recommendation: run a one-week, one-screen spike on an internal-only surface; if it clears, use it for internal tooling and keep it off customer-facing product.

For engineering — the honest version: Treat this as a template repo, not a dependency. Clone it, run one real CRUD entity end-to-end (migration → model → table → form → panel registration → built assets) inside a day, and judge it on whether the conventions fit our habits. Keep domain logic behind our own actions/services so a Zeus table cell calls $record->recalculateTotal() rather than holding logic inline — that's the exit ramp. Publish-then-override only, and maintain an OVERRIDES.md that becomes our upgrade checklist. Prefer panel-provider registration, published views, and sibling Blade components as extension points; never patch vendor classes or extend internal form/table base classes. Verify the built artifact after any major, not the Vite dev server.

For finance/procurement: Zero license cost, zero vendor contract, zero renewals. The real cost is engineering and design time on major upgrades (roughly one per Laravel major, with Tailwind changes as the dominant risk) plus the residual risk of an unmaintained upstream. We mitigate that by scoping to internal surfaces and by pre-committing to a fallback — hand-rolled screens or Filament — so a stall costs us a rewrite of a handful of admin pages, not a replatform.

The one-line pitch: A free accelerator for internal admin screens that we can adopt in a week and abandon in a week — worth it precisely because the exit is cheap.