Kirby Blade Laravel Package

Product Decisions This Supports

• Template engine standardization: Decides whether our PHP web properties converge on a single templating language (Blade) across both Kirby CMS sites and Laravel applications, reducing context-switching and duplicated component libraries.
• Build vs. buy vs. native: Frames the choice between (a) adopting this package, (b) building a bespoke Kirby↔Blade bridge internally, or (c) staying on Kirby's native PHP templates / the Twig plugin. The package is small enough to fork, which changes the calculus.
• Component-driven design systems: Enables reusable Blade components, layouts, slots, and directives in Kirby front-ends — a concrete enabler for design-system work and shared UI kits with our Laravel products.
• Hiring and team topology: Lets Laravel-experienced engineers contribute to Kirby projects without learning a second templating paradigm; influences whether we staff Kirby work from the Laravel pool.
• Platform roadmap / migration bets: Informs whether Kirby is a viable CMS for projects currently served by Laravel, or whether we consolidate the PHP stack around shared tooling.
• Vendor and dependency policy: A live test case for how we treat small, single-maintainer OSS dependencies (pinning, vendoring, fork readiness) — relevant to any "can we depend on this?" decision.

When to Consider This Package

Consider adopting when:

• The team already has meaningful Laravel/Blade expertise, or we run both Laravel and Kirby in the same portfolio.
• The site needs heavy componentization, layout inheritance, or a reusable UI kit that should be shared with Laravel front-ends.
• We are standardizing developer experience across PHP projects and want one mental model for templates.
• We accept the risk profile: 22 stars, 0 dependents, single maintainer, MIT license — and are prepared to pin versions, monitor releases, and fork if maintenance lapses (last release June 2025 shows recent activity).
• Target is Kirby 4 or 5 only; the package is explicitly scoped there.

Look elsewhere when:

• The project is a simple marketing/brochure site where Kirby's native templates are sufficient — Blade adds a dependency for little gain.
• We need vendor-backed support, SLAs, or an established plugin ecosystem — this is a solo-maintainer package, not an officially supported plugin.
• The team has no Blade experience; the learning curve plus low adoption means fewer community answers and higher bus-factor risk.
• Performance or minimal-footprint constraints dominate (extra templating layer, additional dependency surface).
• Governance requires proven adoption (dependents, security posture, contributor diversity) before approving a dependency.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed bridge that lets our Kirby CMS sites use Laravel's Blade templates — the same templating engine our Laravel teams already know. The upside is developer velocity, a single templating skill set across our PHP estate, and reusable UI components between products, which can reduce build time and onboarding cost. The downside is dependency risk: it is a young project (22 stars, one maintainer, no downstream dependents), so I recommend a time-boxed pilot in a low-risk internal project, with version pinning and a documented exit path — the templates remain plain PHP/Blade, so portability is high. We should not make it a platform-wide standard until the pilot validates maintenance health.

To engineering: Adopting this means committing to a thin abstraction over Kirby's rendering layer. We need to validate it against our Kirby upgrade cadence, confirm test coverage for our component patterns, and decide whether to fork-and-vendor under our own namespace to neutralize the single-maintainer risk. Budget a short spike, not a migration.