Theme Agency Laravel Package

Product Decisions This Supports

• Build vs. buy for the front end. capell-app/theme-agency is a prebuilt agency-style front end for the Capell CMS (a Laravel-based content platform). Adopting it removes the cost of designing and building page templates, navigation, footers, and content-layout scaffolding from scratch — the decision becomes "customize a theme" instead of "commission a design system."
• Stack standardization / roadmap. Choosing this package is effectively a decision to standardize on Capell + Blade-rendered themes for client sites. That is a multi-release commitment, not a one-off install, so it belongs in the platform roadmap review, not a sprint ticket.
• Scoping the theme/core boundary. It clarifies what is presentation (this package) versus content modeling, media, and modules (Capell core). That boundary determines where custom engineering hours actually go and how much of the work is reusable across clients.
• Theme-per-client vs. single design system. A swappable theme package supports a "one theme per client, shared core" delivery model. If the team wants a single unified design system across all properties, a standalone theme package adds a layer you may not want.
• Maintenance-cost modeling. The v1.0.45 → v1.0.50 range is five patch-level increments with an auto-generated diff link as the only changelog. That signals low churn and low breakage risk, but also thin release documentation — budget review time for reading diffs rather than release notes, and treat "no documented breaking changes" as an inference, not a guarantee.
• Release read for v1.0.50 specifically. Patch-level version bump, no deprecations or breaking changes announced. This does not change an adoption decision; it only confirms the package is actively but incrementally maintained. The absence of narrative release notes is itself a (minor) process-maturity data point worth tracking across future releases.

When to Consider This Package

Consider it when:

• You are already on Capell, or are seriously evaluating it, and need a marketing/agency site rather than a bespoke application.
• Your team is comfortable in Laravel and Blade and prefers server-rendered views over maintaining a separate JS/SPA front end.
• You want editable content for non-technical stakeholders with a credible visual starting point, and you expect to override views rather than fork the package.
• You are time-boxed — a first presentable page in days, not weeks, is the primary success metric.
• You can pin the version and accept a young, small-ecosystem dependency with informal release notes.

Look elsewhere when:

• You are not on Capell. The package is coupled to the core CMS; it is not a drop-in theme for arbitrary Laravel apps.
• You need a headless or API-first architecture (Next.js, mobile clients, multi-channel). A Blade theme is the wrong layer.
• The design is heavily bespoke. If most templates will be rewritten, the theme's value drops toward zero and a clean build is cheaper to own.
• You require documented changelogs, deprecation policy, LTS windows, or vendor SLAs for compliance or procurement.
• You need a large hiring pool or third-party plugin ecosystem around the theme layer.

How to Pitch It (Stakeholders)

For executives: This is an open-source front-end theme for a Laravel CMS that gets a client marketing site to a presentable first version significantly faster, with no license cost. The trade-off is ecosystem risk — it is a small, early-stage project, so the mitigation is to pilot it on one low-risk property, pin the version, and keep the option to fall back to a conventional build. The latest release is a routine patch bump with no announced breaking changes, so there is no urgency and no re-planning required.

For engineering: Plain Composer package, Blade views, publishable and overridable — no runtime magic beyond standard Laravel service-provider registration. Upgrades from 1.0.45 to 1.0.50 are patch-level, so upgrade friction should be minimal; read the commit diff before bumping, because the release notes are an auto-generated compare link rather than a curated changelog. Watch upstream repo activity and issue response time as the leading indicators of long-term viability.

The ask: Approve a one-property pilot with a pinned version, plus a short spike to confirm how much of the theme we would realistically override. Revisit the standardization decision once the pilot ships and we have real override-cost data.