Common Laravel Package

Product Decisions This Supports

• Shared-kernel vs. duplicate-and-diverge. The core decision this package informs is whether cross-cutting Laravel concerns (base models, traits, middleware, service providers, health/readiness endpoints, config defaults, logging and audit conventions) live in one maintained dependency or get copy-pasted into each service. At 0 dependents and 0 stars, the package is not evidence of a healthy shared kernel — it is evidence that one exists informally and may not yet be consolidated.
• Build vs. buy vs. borrow. For generic concerns (audit logging, permissions, health checks, HTTP client wrappers), mature community packages win. This package is only justified for the Network-Rail-specific residue that no vendor will ever build. The PM decision is to draw that line explicitly rather than letting an internal package absorb generic scope.
• Roadmap sequencing. Adopting a shared base makes later cross-service capabilities cheaper: unified audit trail, consistent observability, single sign-on, uniform error envelopes, one compliance posture for accessibility and security review. Choosing not to adopt pushes those costs into every future service.
• Use cases it plausibly serves. Internal admin and reporting surfaces over operational data, integration middleware to and from enterprise systems, and back-office tooling that must satisfy a common audit/access baseline. This is infrastructure, not differentiation — it should reduce cycle time on compliance boilerplate, never appear on a customer-facing roadmap.
• Portfolio hygiene. A zero-dependent, zero-star internal package is a bus-factor decision as much as a technical one. The PM question is not "is this good code" but "who owns it in 18 months, and what happens to the three services importing it if they don't."

When to Consider This Package

Consider it when:

• You are inside, or contracted to, Network Rail Business Systems and already inherit the surrounding conventions — the abstraction is tuned to that domain and will not generalize.
• You run two or more Laravel services on the same major Laravel and PHP version and are paying a measurable duplication tax on base classes, traits, and providers.
• You need one enforcement point for cross-cutting policy (audit, headers, config defaults, error shape) and can accept a shared dependency's upgrade cadence.
• You have at least one engineer who will read the source, because there is no meaningful public documentation, no community, and no dependent projects to surface breakage for you.
• The alternative is a fourth hand-rolled copy of the same helpers.

Look elsewhere when:

• You are outside the organization. The 0-star / 0-dependent signal means no external validation and no ecosystem pressure to keep the API stable or documented.
• You need a semver-stable, documented contract for a public or multi-vendor product.
• You are on a different Laravel major, are polyglot, or want framework optionality — a handful of local traits will cost less than adapting this one.
• The "common functionality" overlaps with well-maintained community packages. Prefer those; scope this down to the organization-specific remainder.
• You cannot secure a named maintainer and a second reviewer.

Due diligence before committing: read the changelog and the last twelve months of commits; confirm supported Laravel and PHP ranges; check whether it pins transitive dependencies in ways that will block your upgrade path; verify license headers and any organization-specific config assumptions baked into the defaults. Treat the listed 2026-10-21 release date with caution — a release dated ahead of today is typically an automated or scheduled tag, not proof of active roadmap investment.

How to Pitch It (Stakeholders)

To executives: This is not a product — it is internal plumbing that lets several Laravel applications share one set of standards. The value is cost avoidance: less duplicated code, faster security and audit compliance, fewer divergent implementations to review. There is no license cost (MIT), but there is an ownership cost, and it is real. Approve it as a platform standardization line item with a named owner and a review cadence, not as a feature investment. Framing it as "free" is the failure mode; framing it as "one maintainer instead of four codebases" is the win.

To engineering: Adopt it as a pinned dependency behind a thin internal interface so we can swap or fork without touching call sites. Start with one non-critical service, measure upgrade friction across a single Laravel minor-version bump, then roll out. Treat it as our code: write the README and compatibility matrix upstream, because the package has no external users to report breakage and we will be the first to find it. Budget the maintenance explicitly — a shared package with no owner is a scheduled outage.