Manticore Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for cross-cutting capabilities. A Laravel/PHP package is almost always a "buy" decision on a problem the team could hand-roll in a sprint or two. This assessment frames the trade: engineering days saved now versus a long-term maintenance, upgrade, and security surface you now own a dependency on.
• Roadmap sequencing. Adoption cost is front-loaded (integration, config, tests) and value is realized on the next feature that would otherwise rebuild the same primitive. If that feature is in the next two releases, adopting now compounds; if it's three quarters out, defer and revisit.
• Feature differentiation vs. table stakes. Packages are appropriate for commodity concerns (auth, queues, PDF generation, payment plumbing) and inappropriate for anything a customer would pay you for. This keeps scarce product engineering focused on the differentiators.
• Platform and upgrade planning. The package's supported Laravel and PHP version matrix is a direct input to the annual framework-upgrade budget. A package lagging the current Laravel major is a roadmap constraint, not just a technical note.
• Time-to-market bets. For a v0.x package, the decision is explicitly a bet on a small maintainer's velocity. That is acceptable for internal tooling and dangerous for revenue-path code — which is a product risk decision, not an engineering one.
• Vendor and exit strategy. Any adoption decision should answer: how many hours to remove this dependency if the maintainer disappears? That number determines whether the package belongs in the critical path.

When to Consider This Package

Consider adoption when:

• The problem is commodity. The package solves something adjacent to your core product where differentiating adds no customer-visible value.
• The Laravel version matrix matches your pinned versions, including the next major you plan to adopt within twelve months.
• It is actively maintained. Commits and releases within the last six months, issues receiving responses, and at least one maintainer who is not a single unresponsive individual for anything in the revenue path.
• The abstraction is thin and the exit is cheap. It wraps framework primitives rather than replacing them, so removing it means deleting call sites, not rewriting architecture.
• It has a test suite and you can read the source in an afternoon. Auditability is the real security control for a dependency you cannot patch yourself.
• License and dependency footprint are clean. MIT/Apache, no transitive packages you would not approve independently.
• Adoption cost fits inside one sprint, including configuration, tests, and documentation for the team.

Look elsewhere when:

• It is pre-1.0 and touches money, auth, or data integrity. Version 0.x signals no stability promise; breaking changes between patch releases are normal and will land during your own release cycle.
• It overlaps a core competency. If the package does something customers evaluate you on, you want ownership of the code path.
• Laravel support lags. A package that does not support your current major version will block your framework upgrade, and framework upgrades are security work.
• The maintainer is a single individual with no succession plan and the package is in the critical path.
• The abstraction is heavy. Packages that own your models, migrations, or routing conventions are expensive to leave.
• You would be the first production user. Being an early adopter converts you into a QA resource for someone else's roadmap.

For a v0.0.3 release specifically: this is pre-alpha semantics. Treat it as a spike, not an adoption. Run it in a throwaway branch against a real use case, and make a build-vs-buy call on the outcome rather than on the package's current surface area.

How to Pitch It (Stakeholders)

To executives: I am recommending we evaluate a small open-source Laravel package rather than build this capability ourselves. The expected return is roughly one to two engineering weeks avoided on the next release, against a modest ongoing cost of tracking upgrades. The reason this is a decision and not a formality is that the package is early-stage (v0.0.3) and maintained by a small team, so I am proposing we pilot it on a non-critical path and hold off on anything customer-facing or payment-related until it reaches a stable 1.0 with a track record. Worst case we spend a few days and revert; we are not locked in.

To engineering: Treat this as an experiment, not an adoption. Spike it in a branch against one real use case and report back on three things: how much code it actually replaced, how hard it would be to remove, and whether it supports the Laravel major we plan to be on next year. If the exit cost is low and it holds up, we adopt it for commodity work only and keep it out of the revenue path until it has a stable release and more than one maintainer. If it fails any of those checks, we build the small version ourselves and revisit in two quarters.

Framing both audiences will accept: the decision is reversible, the pilot is time-boxed, and the criteria for graduating from pilot to adoption are written down in advance — so this does not become a dependency we drift into by default.