Craft Laravel Package

Product Decisions This Supports

• Build vs. buy for content management. This package is the cheapest possible proof-of-concept for "buy" (well, adopt — Craft is free for solo/small use, paid Pro for commercial). Spinning it up takes minutes, so a PM can compare Craft against WordPress, Statamic, or a headless SaaS on real content models rather than slideware. Note the framing correction: despite being filed under PHP/Laravel packages, this is not a Laravel package — it's a Composer starter project for Craft CMS. That distinction matters for the build/buy conversation, because nothing here couples you to Laravel conventions.
• Time-to-first-value as a roadmap input. Because composer create-project craftcms/craft produces a runnable project (with .env.example, DDEV config, and a sane directory layout), the package effectively defines your floor for onboarding effort. Use it to set expectations: "day one = content model, not scaffolding."
• Standardizing internal project baselines. If your org ships multiple Craft sites, this repo is the reference implementation to fork. Deciding to fork-and-pin vs. track upstream is a real roadmap decision with ongoing maintenance cost — and one a PM should own, because it determines who absorbs upgrade work.
• CMS evaluation and platform bets. 0BSD licensing is the relevant signal for legal/procurement: no attribution requirement, no copyleft exposure, no vendor license negotiation to ship your own starter variant. That materially shortens the legal review step in a platform decision.
• Feature scoping for content-heavy products. Multi-site, localization, and authoring UX are Craft's differentiators. Standing this up early lets you validate whether those features belong in v1 or v2 instead of committing to a DXP contract you can't back out of.
• Hiring and vendor-conversation leverage. A working PHP/Craft baseline gives you concrete artifacts to hand agencies and candidates, replacing abstract requirements docs.
• Honest caveat on the signal: 206 stars and a low opportunity score (1.14) tell you this is infrastructure-shaped, not differentiated. It will not win a bake-off on its own merits — Craft's authoring experience does. Treat the package as an enabler, not a differentiator, and don't let it anchor your platform choice.

When to Consider This Package

Consider it when:

• You are starting a greenfield PHP site where editors, not developers, control content, and you've already decided Craft is a serious candidate.
• Your team is comfortable with PHP/Composer and wants a licensed, self-hostable alternative to WordPress or to a headless SaaS content API.
• You need multi-site / localization content out of the box and want to evaluate that on a real install.
• You intend to standardize a house starter across several projects and want a vetted baseline rather than hand-rolling one.
• Procurement or legal needs a clean license position — 0BSD removes that friction entirely.

Look elsewhere when:

• You are Laravel-native and want first-party integration. Craft integrates, but it is not a Laravel package; if your team's mental model and tooling is Eloquent, queues, and Blade, evaluate statamic/cms (Laravel-native) or plan explicitly for the integration seam. Choosing Craft here is a deliberate architectural exception, not a default.
• You need headless-only, API-first content delivery with no rendering opinion — a managed content API is likely cheaper to operate than self-hosted Craft plus your own front end.
• You lack PHP hosting/ops capacity. Self-hosting means you own upgrades, PHP version bumps, and database/asset backups. The starter project is not a hosting solution.
• You want a long-lived dependency you can composer require and forget. This is a template — it's meant to be forked and owned. Every upstream change is a diff you evaluate manually. If nobody owns that, drift is guaranteed.
• You're on a non-PHP stack. Craft can serve as a headless backend, but you're paying PHP ops costs for a GraphQL endpoint you could buy.
• You need enterprise DXP capabilities (complex personalization, marketing automation, digital asset management at scale). Craft is a CMS, not a DXP.

The operational question to resolve before adopting: who owns the fork? The craftcms/craft repo is a moving baseline; pinning a tag and reviewing upstream releases is a recurring cost that should appear on a roadmap, not in a surprise ticket.

How to Pitch It (Stakeholders)

For executives: We can stand up a production-shaped CMS baseline in under an hour, with zero license cost and zero legal exposure — the starter project is released under 0BSD, so we can fork, rebrand, and ship derivatives without attribution or negotiation. The real decision on the table is not this package; it's whether Craft is the right content platform. This gives us a cheap, reversible way to answer that with a working prototype instead of a procurement cycle. Downside to be explicit about: it's a starting template we must own and upgrade, not a managed service, so it carries a modest ongoing maintenance line.

For engineering: composer create-project craftcms/craft yields a conventional Craft layout with .env.example and DDEV config — a starting point, not a dependency. Recommended usage: fork it, pin a tag, keep our divergence minimal and documented, and review upstream releases on a schedule so the diff stays reviewable. Two clarifications worth stating up front: this is not a Laravel package (no framework coupling), and it is not a library we require — it's scaffolding, and scaffolding decays if unowned. Budget a named owner for the fork and an upgrade cadence tied to Craft's major releases. If the team's center of gravity is Laravel and that ownership burden looks like a poor trade, raise it now — that's the strongest argument for evaluating a Laravel-native CMS instead.