Preventgo Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on the integration layer. The vendor publishes an SDK, so the decision is "depend on their wrapper" vs. "write a thin internal HTTP client." With 0 stars and 0 dependents, the buy side is effectively empty — this behaves like a private, single-tenant wrapper that happens to be on Packagist, not a supported product. The v2.0.1 patch does not change that.
• Compliance/risk feature scoping. Whatever PreventGo does (screening, verification, risk checks — confirm with the vendor, the repo name is the only signal), the bundle's public surface tells you which capabilities are first-class versus which you'd be calling as raw HTTP. That's a direct input to sizing a compliance or onboarding feature.
• Framework architecture. Despite being filed as a "Laravel/PHP package," it is a Symfony Bundle — it assumes Symfony's DI container, bundle registration, and a config tree. If your stack is Laravel, you are not adopting this package; you are reading it as documentation and porting the service classes. That reframes the effort estimate significantly.
• Framework version floor is now a real constraint. Symfony 7 compatibility only landed in v2.0.1 (a fix, not a feature). Treat 2.0.1 as the minimum viable version if your stack is Symfony 7; anything earlier is a different, less-supported target. If you're on Symfony 5/6, earlier tags remain usable but the project is clearly tracking upstream Symfony releases reactively.
• Roadmap signal, not market signal. The parent org (Mon Petit Placement, a regulated investment platform) publishes this for its own use. If they are live on PreventGo, this bundle is the canonical integration path for that vendor — a useful data point when comparing vendors on "do they have a real, in-production PHP integration."
• Not a viability proxy. Zero stars and zero dependents mean adoption metrics are uninformative here. Do not use popularity as a proxy for vendor health in either direction. The Symfony 7 fix arrived via an external pull request (#3), which is a mild positive on responsiveness but is not evidence of a user base.

When to Consider This Package

Adopt when:

• You are on Symfony 5/6/7 and want DI-wired configuration instead of hand-rolled service wiring. On Symfony 7, pin >=2.0.1 — that is the release where compatibility was fixed.
• You already have a PreventGo contract and account — this is not how you evaluate the vendor.
• You're comfortable vendor-forking it into your own namespace. Assume you own the maintenance; 0 dependents means no community backstop, and a one-line compatibility patch is the entirety of the recent upstream activity.
• Its Composer constraints, supported Symfony matrix, and release cadence fit your dependency policy.

Look elsewhere when:

• You are on Laravel or any non-Symfony framework. The bundle plumbing is dead weight; take the request/response handling and write a thin client against your HTTP abstraction.
• You require SLA-backed support, meaningful semver guarantees, or a documented security disclosure process. None of these are evidenced — and a Symfony 7 fix shipping as a patch on a 2.x line suggests versioning is pragmatic rather than contract-driven.
• You need a general-purpose identity/KYC/screening library — choose a vendor with multiple public SDKs and visible consumers, so your integration isn't the only one in existence.
• The call sits on a compliance-critical path where a single-maintainer dependency is an unacceptable single point of failure.

How to Pitch It (Stakeholders)

For executives: This is a small integration package that connects our PHP stack to the PreventGo API — it is not a strategic dependency. It's published by a single organisation with no public adopters, so we should treat it as a reference implementation rather than a supported product. A recent patch added Symfony 7 compatibility; welcome maintenance, but it is a compatibility fix from a single external contributor, not a sign of a maturing ecosystem. Our recommendation stands: pilot it behind our own internal adapter interface, so the vendor call stays swappable and the package itself never becomes load-bearing. Cost is low (roughly half a day to vendor it into our own namespace); the risk of not wrapping it is finding out later that we can't replace it.

For engineering:

• Wrap it behind an interface we own (PreventGoClientInterface or equivalent). Nothing outside the adapter imports the bundle's types.
• Pin the exact version and vendor-fork it into our namespace; treat upstream as a source of patches, not a dependency. Minimum 2.0.1 if we're on Symfony 7 — earlier tags predate the compatibility fix.
• Put Symfony 7 in the fork's CI matrix explicitly. The upstream fix was reactive, so don't assume untested framework versions work.
• Strip the Bundle layer entirely if we're on Laravel — reuse the client and DTOs, not the DI wiring.
• Add contract tests against the PreventGo sandbox so an upstream change surfaces in CI, not in production.
• Watch the upstream repo for releases; reassess if it gains real dependents or the vendor starts publishing it themselves.
• Confirm licensing and the vendor's support expectations before this reaches a compliance-critical path.