Ratsit Bundle Laravel Package

Product Decisions This Supports

• Sweden market entry: If Sweden is on the roadmap, this package anchors whether Swedish person/company lookup (name, address, age, registry data) belongs in onboarding, CRM enrichment, fraud review, or KYC. The bundle itself is only the plumbing — the real product decision is whether that data capability is in scope at all.
• Build vs. buy on the integration layer: The bundle is a thin Symfony DI wrapper around jongotlin/Ratsit. For a Laravel shop, the decision is "do we install the underlying jongotlin/ratsit client and write ~1 day of service-provider glue, or inherit someone else's glue?" For nearly every team, owning the glue wins — retries, caching, logging, and PII handling all want to be ours.
• Framework standardization: This is a Symfony bundle with no Laravel service provider, facade, or publishable config. It will not boot in Laravel as shipped. That is itself a decision input: your Swedish data service should be a Laravel-native adapter around the vendor SDK, not a carried-over Symfony dependency.
• Vendor selection: Forces comparison of Ratsit against alternates — UC, Creditsafe, Bisnode/D&B, Veriff/Persona — on coverage, pricing, freshness, rate limits, and the legal basis for processing personnummer.
• Feature scoping: Supports scoping an MVP to read-only lookup and enrichment. Monitoring, write-back, and decisioning flows carry materially different compliance weight and should be explicitly descoped.

When to Consider This Package

Consider it only if:

• You are on Symfony with PHP 8+ and want to skip writing container glue. On Laravel, use the jongotlin/ratsit library directly — the bundle provides no Laravel asset.
• Sweden is a funded, committed market segment, not a slide.
• Your need is lookup/enrichment, not compliance-grade KYC attestation — the bundle gives API access, not an audit trail or verification guarantee.
• The use case is internal tooling or a prototype where a dependency failure is an inconvenience, not a customer-facing outage.
• You will pin and vendor/fork it. MIT permits this; assume you will need to.

Look elsewhere if:

• You need SLAs, a security review sign-off, or a maintained dependency. Zero stars, zero dependents, single maintainer — assume high abandonment risk and a bus factor of one.
• You need a documented GDPR Article 6 basis, a DPA, or data-residency guarantees. The bundle offers none and cannot.
• You require high-volume or real-time throughput — you must audit the underlying client's transport, caching, and rate-limit behavior yourself.
• Anything is customer-facing without a fallback path when the third-party API is unavailable.
• You are on Laravel and want a first-class package. Use the SDK.

How to Pitch It (Stakeholders)

To executives: This is not a strategic dependency — it is a small, MIT-licensed convenience wrapper around a third-party Swedish registry API. Recommendation: do not adopt the bundle as-is. The strategic question is whether Ratsit (or an alternate) is the right data vendor for Sweden. The integration itself is roughly one sprint of internal work, and the framework mismatch means on Laravel it is a non-starter anyway.

To engineering: The bundle contributes ~100–200 lines of Symfony DI wiring and configuration on top of jongotlin/Ratsit. That is a low-value surface area to inherit from a package with no demonstrated maintenance. On Laravel, consume the underlying SDK directly and adapt it with a ServiceProvider behind an internal PersonLookup interface — you keep control of retries, caching, logging, error handling, and personnummer normalization, all of which you will want to own anyway when PII is in the payload.

Risk posture: Zero stars, zero dependents, no observable maintenance cadence. There is no security posture to review and no community to lean on. Do not place it on any path that touches personal data without an independent legal and security review of the underlying service — the bundle does nothing to mitigate that.

Ask: Approve a one-week spike to evaluate Ratsit's API terms, pricing, rate limits, and GDPR posture against two alternates, returning a build-vs-buy recommendation on both the vendor and the integration layer. Do not approve adoption of the bundle itself.