Website Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy the public-site presentation layer. This is a prebuilt front-end layer (routing, controllers, Twig templates, navigation, SEO metadata) for content managed in the Integrated CMS. The decision it informs: do we hand-roll page rendering, slug routing, and canonical/SEO scaffolding, or start from a vendor baseline and customize?
• Time-to-first-page scoping. For a marketing site, brochure site, or documentation portal backed by Integrated, the bundle can compress "empty repo to rendered page" from weeks to days. That is a direct input to launch dates, fixed-bid estimates, and demo timelines.
• Architecture boundary: CMS-owns-front-end vs. headless. Adopting it forces an explicit call — does Integrated own presentation conventions, or do we treat it as a content API and own rendering in our own stack? That line drives hiring, testing strategy, and the future cost of swapping CMSs.
• Multi-site / multi-brand reuse. If several properties share one content model, the bundle is a candidate shared base each site extends, reducing duplicated front-end work — if the spike shows clean override mechanics.
• Treatment decision on unproven code. Zero stars, zero dependents, near-zero composite score. The real product decision is risk posture: adopt it as a codebase we fork and own, not as a supported dependency we trust with uptime. Budget maintenance capacity accordingly.
• Roadmap deprioritization. If baseline rendering is covered acceptably, defer the custom routing/design-system investment and redirect capacity to differentiators (personalization, commerce, integrations).

When to Consider This Package

Consider it when:

• You have already committed to Integrated as your CMS — the value proposition collapses without it.
• Your stack is Symfony/PHP with Twig, matching the bundle's conventions. Note the framing risk: it is marketed in Laravel/PHP circles but is a Symfony bundle. If your application is Laravel-first, expect adaptation work, not a drop-in.
• You need a conventional, content-led public site — pages, menus, metadata — not a highly interactive product surface.
• You have engineering capacity to fork, vendor, and maintain the code, and appetite for a two-to-four-week ramp-up on the Integrated content model and override conventions.
• You are running a timeboxed proof of concept and want the fastest credible path to a rendered page for stakeholder review.

Look elsewhere when:

• You need community support, a security-patching cadence, or a contributor base — none exist here; zero stars and zero dependents mean every defect is yours to find.
• Your architecture is headless/decoupled (SPA, Next.js, mobile clients). Consume Integrated's content API directly instead of adopting its rendering opinions.
• You have hard performance, caching, or multi-tenant requirements a thin, unproven bundle has not solved — assume you own the caching layer and cache-purge behaviour until proven otherwise.
• You need accessibility compliance, i18n, previews/draft content, or complex editorial workflows out of the box. Assume you build these.
• You are Laravel-only with no appetite for a second Symfony deployable — the satellite-service pattern costs you two pipelines, two session models, and duplicated design-system work.

How to Pitch It (Stakeholders)

For executives: This is a small, vendor-published front-end accelerator for sites whose content lives in the Integrated CMS. It is not a strategic platform bet — it is a shortcut that may save weeks on a content-driven site launch if we are already on Integrated and running a compatible Symfony/PHP stack. It has no community traction and no external dependents, so we should treat it as sample code we adopt and own, not a supported product we rely on. Recommendation: timebox a two-week evaluation against our actual requirements, gate it behind a security and licence review of the Integrated backend contract, and proceed only if the savings are real and we are comfortable maintaining a fork.

For engineering: Expect a baseline rendering layer — routing, controllers, Twig templates — bound to Integrated's content model and Symfony conventions. Plan to fork it into our repo, pin exact versions, and own the Symfony-major upgrade path; there is no community compatibility folklore to lean on. Do not add it as an unexamined dependency: audit test coverage, security posture, and PHP/Symfony/Twig version support before production. Design a containment plan — keep design tokens, asset pipeline, and SEO metadata generation outside the bundle, enumerate bundle-registered routes against host-app routes in CI, and add visual regression tests on key pages so upgrades cannot silently break templates. If our core is Laravel, evaluate Integrated's API headlessly first and treat this bundle as documentation of the content model rather than a runtime dependency.

For product: The evaluation criteria are concrete: first rendered page in under two weeks, a clean template-override mechanism, graceful behaviour when the backend is unavailable, and a documented exit cost to replace the bundle. If any of those fail during the spike, the correct decision is headless consumption of Integrated's API, not adoption.