Voyager Frontend Laravel Package

Product Decisions This Supports

• CMS layer selection (build vs. buy vs. assemble): Informs whether Voyager plus a front-end scaffold is an acceptable content platform versus a headless CMS (Contentful, Sanity, Strapi) or a managed product — the package only makes sense as part of a Voyager commitment, so it forces that upstream decision first.
• Legacy marketing site disposition: A concrete input to "maintain, rebuild, or replace" for any property already running Voyager-era Laravel; the archived status turns this into a depreciation-schedule question rather than a feature question.
• Scope and effort estimation for CRUD-backed public pages: Shows the realistic shape of a BREAD-driven site (routes, controllers, Blade templates, block/partial composition), which is useful for sizing a comparable in-house build even if you never install it.
• Roadmap sequencing for content-driven surfaces: Helps classify which surfaces (landing pages, blog, docs, campaign microsites) are commodity and can ride on a thin admin-plus-front-end pattern, versus which need investment.
• Fork vs. depend vs. ignore: Because the repo is archived and MIT-licensed, the real decision is whether to vendor a copy as a reference implementation, absorb select patterns into your own codebase, or exclude it from evaluation entirely.
• Technical debt triage: For an existing install, quantifies exposure — no security patches, no Laravel-version tracking — and feeds the case for a migration epic.

When to Consider This Package

• You are already on Voyager and running a Laravel version contemporary with the package (roughly Laravel 5.5–7 era); here it can save genuine scaffolding time on public-facing routes and views.
• You need a small, low-traffic, content-managed site — a brochure site, campaign microsite, or internal tool with a public layer — where the admin already exists and the front end is thin.
• You are doing a spike or proof of concept and want a working pattern to react to, not code you intend to operate for years.
• You want a reference implementation for how a BREAD-driven Blade front end is structured, to inform an in-house build.
• Look elsewhere if: you are starting a new project, need current Laravel support or PHP 8.2+, have any compliance or security-patch obligation, need API-first/headless delivery, multilingual content, commerce, or search at scale, or need a vendor who will answer a support ticket. An archived repo with its last release in January 2020 and a low health score is a maintenance liability, not a foundation — the absence of a maintainer is itself the deciding criterion.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed add-on that fills in the public-facing half of Voyager, a Laravel admin panel. It is not a strategic asset — the project was archived and has had no release since early 2020, so it carries no security-update path and no support. The honest framing: it is a short-term accelerator for a site we are already running on Voyager, or a free reference design for something we build ourselves. It is not a candidate for new investment, and adopting it creates a known future migration cost. Recommend we treat any existing usage as technical debt with a scheduled exit, and treat the package as evidence for the broader CMS decision rather than a decision in itself.

To engineering: Treat this as a reference implementation, not a dependency. It shows the route/controller/Blade pattern for surfacing Voyager-managed content, which is useful whether or not you install it. If you do adopt it, vendor it — pin the commit, assume ownership of patches, and check PHP and Laravel compatibility against our runtime before committing, because nothing upstream will track it for us. Budget the exit: any surface built on it should be independently replaceable, with content access isolated behind our own layer so a CMS swap does not touch presentation code.