Monnaie Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the capability the package covers. The core PM question is whether adopting an off-the-shelf Laravel package removes weeks of internal work or just adds a dependency your team has to babysit. At v0.1 the defensible answer is "evaluate," not "standardize."
• Roadmap sequencing. If the package maps onto something already on the near-term roadmap, it can pull that work forward a quarter — conditional on the public API stabilizing. Until then, plan for it as an accelerator for a spike, not a committed delivery date.
• Feature scoping / de-scoping. A package that covers a solved problem (auth, admin scaffolding, integrations, payments plumbing) lets you re-point engineering at differentiating work. Confirm the package's scope matches your actual user journeys, not just its README demo path.
• Upgrade-cost forecasting. v0.1 with no published release notes is a strong signal of a pre-stable API. Any plan that depends on it should carry an explicit churn budget and an interface boundary so it can be swapped out.
• Vendor/dependency risk register. Adds an entry whose bus-factor, release cadence, Laravel/PHP version support matrix and security disclosure process all need tracking alongside your other third-party dependencies.
• Make-vs-fork. Decides whether you consume it as a dependency, fork it, or lift the ideas and reimplement — a fork is a permanent maintenance tax and should be a deliberate choice, not a fallback.

When to Consider This Package

Consider it when:

• The capability is already on your roadmap, or you have a hand-rolled version you'd rather not maintain.
• Its Laravel and PHP constraints line up with what your app runs today and the next LTS you expect to move to.
• It follows normal Laravel package anatomy: auto-discovered service provider, publishable config, migrations, documented extension points rather than "edit the vendor file."
• There's visible CI, a test suite, tagged releases, and a stated support policy.
• There's a clean exit: you can wrap it behind your own interface, so removal is a refactor and not a rewrite.

Look elsewhere or defer when:

• It's v0.1 with no changelog or release notes — treat as evaluation-only and keep it out of production paths.
• It duplicates something Laravel ships natively, or something your team already owns and understands.
• Adopting it means forking core behavior or fighting the framework's conventions.
• Single maintainer, no security policy, no recent commits, no issue triage.
• You need a guaranteed API contract to support a multi-year commitment — a 0.x package cannot give you that.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, low-cost Laravel add-on that could save meaningful build time on a capability we already need. The catch is maturity: it's a v0.1 with no published release notes, so the API can change under us. Recommendation is a time-boxed evaluation, not a platform commitment. The decision I need is approval for a short spike — roughly three to five engineering days — with a clear recommendation to adopt or walk away at the end of it.

For engineering (the ask): Take a throwaway branch, install the package, run its test suite and exercise the primary use case end to end. While you're in there, check the boring things that predict pain later: service provider and config hygiene, whether migrations are reversible, the declared Laravel/PHP support matrix, and how tightly it couples to framework internals. Exit criteria are a documented integration cost estimate, a named owner, and a fallback plan for the day the package stalls or we need to remove it. If any of those can't be produced, the recommendation defaults to no.