Platform Laravel Package

Product Decisions This Supports

• Build vs. buy vs. fork for admin/CMS surface. asgardcms/platform is a complete, working Laravel CMS application — not a library. Evaluating it forces the real question: do we want to own an application, or compose one from maintained parts? That decision shapes months of roadmap, not a sprint.
• Architecture direction: modular monolith. Asgard's package-per-module layout (its own module registry, nwidart/laravel-modules lineage) is a concrete reference for whether module boundaries are worth the ceremony on our content surface.
• i18n content model. Asgard treats translation as first-class at the entity level rather than as a bolt-on. That is a design decision we will have to make either way, and this repo is a worked example of the trade-offs.
• Roadmap kill-switch. 788 stars, MIT, last release 2018-09-05, zero dependents. That combination is enough to close the "should we use this?" question permanently and avoid an engineering spike.
• Vendor/ecosystem risk scoring. Zero dependents is the strongest signal in the dataset: nobody in the ecosystem has required this as a dependency, because the intended use is cloning the app, not installing it.

When to Consider This Package

Consider it only when:

• You are designing a modular, multi-language Laravel CMS and want a read-only architectural reference — module boundaries, per-locale content storage, admin panel structure.
• You already run a legacy Asgard-based application on Laravel 5.x and need migration context (in which case the plan is exit, not adoption).
• You are benchmarking admin-panel ergonomics inside a heavily modularized codebase.

Look elsewhere when:

• You need a maintained dependency. No release since September 2018, no PHP 8.x / Laravel 10+ support, no security patch stream, effectively no community.
• You plan to composer require it. You cannot — it is the application shell. Adoption means forking the whole app and owning it indefinitely. Zero dependents confirms this.
• You need an upgrade path, SLA, or vendor contact. None exist.
• You want the same shape today. Compose nwidart/laravel-modules (the module engine alone) with Filament or Nova for admin, or use Statamic/October for a turnkey CMS. The 28.96 score and 27.65 opportunity score are consistent with "reference artifact, not candidate."

How to Pitch It (Stakeholders)

To executives: This is a mature-looking but abandoned open-source CMS application — 788 GitHub stars, MIT licensed, last shipped in 2018. It is not a component we can install and depend on; adopting it means forking an entire application and owning its maintenance, upgrades, and security forever, with no vendor and no community behind it. Recommendation: do not adopt. Budget impact: zero. The only cost we avoid is a wasted engineering spike.

To engineering: The value here is architectural, not code. Read it for the module boundaries and the per-locale content model, then build the equivalent on a supported stack — nwidart/laravel-modules for the module layer, Filament or Nova for admin, current Laravel. Be explicit that a hands-on spike is a trap: the repo is Laravel 5.x-era and will not boot on modern PHP without substantial rework, which is time we would spend rebuilding rather than learning.