Amethyst Common Laravel Package

Product Decisions This Supports

• Build vs. buy for internal package scaffolding. This is not an end-user feature; it is a set of base classes and conventions for authoring other Laravel packages (service providers, entities/repositories, configuration, bootstrapping). The relevant product decision is whether to adopt a pre-built scaffolding convention or standardize on Laravel-native tooling. Given the maturity signals, the answer is: use it as a reference architecture, not a dependency.
• Roadmap triage. This package belongs in the "infrastructure experiments / spikes" bucket, not on a committed roadmap. It unlocks nothing a customer sees, and its adoption risk (1 star, 0 dependents, single maintainer) makes it unsuitable as a platform bet.
• Feature enablement for a modular admin/CRUD framework. If the product direction involves a plugin-based admin panel, module registry, or CRUD generator, the amethyst pattern is a usable prior art for how to structure that.
• Use cases: internal tooling, package boilerplate, rapid prototyping of modular Laravel packages, evaluation of the amethyst ecosystem before committing to railken/amethyst proper.
• Vendor-vs-depend decision. The library is MIT and tiny; the defensible PM call is to read it, cherry-pick the 2–3 classes that matter, and own that code rather than add a fragile transitive dependency.

When to Consider This Package

Consider it when:

• You are already inside the amethyst-php ecosystem and need the common base classes that its packages expect.
• You are designing your own modular package framework and want a compact, readable reference for conventions (provider bootstrapping, repository/entity separation).
• You are running a time-boxed spike where maintenance risk is explicitly acceptable and throwaway code is fine.
• You need something to fork or vendor — MIT license makes that clean.

Look elsewhere when:

• You need a production foundation with an SLA, security patching, or version-compatibility guarantees. One maintainer, one star, zero dependents is a bus-factor of one and an abandonment risk.
• You need documentation, community support, or Stack Overflow answers — none will exist here.
• You are standardizing on the Laravel mainstream. spatie/laravel-package-tools, Orchestra Testbench, and Laravel's own package discovery solve the same scaffolding problem with orders of magnitude more adoption and maintenance.
• You need a stable public API across Laravel major versions — this package's surface is not governed by a deprecation policy you can rely on.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed utility library — free to use, no lock-in, but also no support signal worth building a plan on (one maintainer, one star, no downstream dependents). Recommendation: do not make it a roadmap dependency. If it saves a week on a spike, use it and move on.

To engineering: The package provides base classes for building amethyst-style packages. The realistic adoption path is patterns, not the dependency: read the source, vendor the few classes we actually use, or reimplement them on top of Laravel's native package discovery and service provider mechanics. That gives us the same scaffolding with a maintainer we control.

Bottom line for stakeholders: Zero cost, zero strategic value, moderate abandonment risk. Treat it as prior art and a possible accelerant for internal tooling — never as load-bearing infrastructure.