Product Decisions This Supports
- Build vs. buy for Laravel-native functionality: v0.1 is the first public release, so this is the earliest possible evaluation point. Treat it as a candidate for a time-boxed spike, not a committed dependency. A 1–2 day prototype against our actual codebase will tell us more than any README at this stage.
- Roadmap de-risking: if this package covers something currently on our roadmap (auth flows, integrations, admin tooling, domain scaffolding), an early spike can shrink an epic's estimate — or kill it cheaply if the package's abstractions don't survive contact with our domain model.
- Internal standards and conventions: Laravel packages often encode opinions (service providers, config publishing, contracts, testing helpers). Early adoption lets us shape our internal conventions around them; late adoption means a migration.
- Use cases that fit an early-stage package: internal tooling, prototypes, spike branches, non-customer-facing services — anywhere a breaking change costs us hours rather than an incident. Not a fit for revenue-critical paths at v0.1.
- Supplier and maintenance risk: a first public release with no documented capability set is a maintenance-risk signal. Record it in the dependency register now so that if a team adopts it, the exit cost is visible before it becomes load-bearing.
When to Consider This Package
Consider it when:
- The package's problem statement overlaps with work already on our roadmap, and we can validate it in a spike without touching production code.
- We can pin the dependency to an exact version and isolate it behind an internal interface, so removal later is a contained change.
- A named engineer owns the spike, with a defined exit criterion (e.g. "reproduces our top 3 use cases in under a day").
- It saves more maintenance effort than we'd spend tracking upstream releases — and we have capacity to track them.
Look elsewhere when:
- It would sit on a revenue-critical or customer-facing path. Pre-1.0 packages carry no stability guarantee, and v0.1 typically means the public API is still being discovered.
- We'd need to fork it on day one — at that point we're maintaining a package, not consuming one.
- A framework-native or already-approved internal solution covers 80% of the need.
- There is no evidence of ongoing maintenance (release cadence, issue responsiveness, test coverage, CI). We cannot assess this from a first release alone.
Immediate gaps to close before any adoption decision: what problem does it solve, what does it depend on, what Laravel/PHP versions it supports, whether it ships tests, and its licence. None of this is knowable from a v0.1 changelog that reads "First public version."
How to Pitch It (Stakeholders)
Executives: An early-stage Laravel package has surfaced that may cover part of our roadmap. We are not adopting it. We're proposing a small, time-boxed engineering spike — roughly one to two days — to determine whether it reduces build effort. Cost is bounded, it touches no production systems, and the outcome is a clear go/no-go with a written recommendation. The downside of skipping the spike is that we build something we could have bought; the downside of adopting blind is an unmaintained dependency in our stack. The spike resolves which risk we're taking.
Engineering: This is a v0.1 first public release. Assume the API will change and that upgrade paths are not yet defined. Any evaluation must run on a branch, pin an exact version, and wrap the package behind an internal interface so we can swap it out. The spike should test our hardest use case first, not the happy path in the README. Report back on: API ergonomics against our domain model, test coverage, dependency footprint, and whether the configuration surface is sane. If it fails on any of those, we write it off and move on — that's a successful spike outcome, not a wasted one.