Validator Es Laravel Package

Product Decisions This Supports

• Spain market-entry gating. The moment any roadmap item requires Spanish customers, suppliers, or vendors to register, be invoiced, or be paid, DNI/NIE and Spanish IBAN validation becomes a blocking checklist item. This package answers "can we ship this?" concretely instead of leaving the feature stuck in legal/ops review while an engineer hand-rolls check-letter math.
• Build vs. buy on a narrow, rules-heavy domain. Spanish ID validation is small in surface area but fiddly in detail — DNI/NIE check letters, CCC check digits, Spanish IBAN structure. MIT-licensed, zero runtime dependencies, one isValid() method. The PM trade is one sprint of engineering redirected toward differentiating work, at effectively zero cost and with near-zero switching cost later.
• Scope calibration for "Spain support." This is the most valuable use of the package as a PM artifact: it forces you to write down precisely how far localization goes. It covers format and checksum only — no CIF/NIF, no existence checks, no non-Spanish IBANs, no passports or driving licences. Documenting those gaps in the spec now prevents sales and compliance from hearing "we validate Spanish IDs" as something stronger than it is.
• Data-quality remediation on existing flows. Even without a Spain launch, if Spanish customers or suppliers already sit in the CRM, billing, or payout pipelines, retrofitting format validation reduces failed payments, reconciliation work, and support tickets from malformed identifiers.
• Risk framing for the roadmap. With ~1 star, 0 dependents, and a single maintainer, adoption is a bet on one person. That is a reasonable bet for a stateless input-validation helper and an unreasonable one for anything a regulator will audit. The PM decision is about blast radius and containment (wrap it behind your own rule layer, pin the version, add your own test vectors), not about the library's intrinsic quality.

When to Consider This Package

Adopt when:

• Spain, or a Spanish-market segment, is on the near-term roadmap and you need DNI, NIE, combined IdCard, CCC, or Spanish IBAN format validation inside a Laravel/PHP app.
• The requirement is genuinely format-only — rejecting malformed identifiers at the form or API boundary before they reach a human reviewer or a third-party verification vendor.
• You accept that integration work is yours. The package ships a bare ValidatorInterface with isValid(), not Laravel Rule objects, translated messages, or FormRequest wiring. Budget for thin wrapper rules, error copy, and tests.
• The output feeds an authority that does the real check — a KYC provider, a bank, a gestoría. Here it is a cheap pre-filter that cuts junk submissions and manual review load.

Look elsewhere when:

• You need existence or identity verification (is this DNI real, is this the person). This validates structure and checksums; treating it as identity verification is a compliance risk, not a feature.
• You need CIF/NIF — the gap that matters most, since B2B Spanish onboarding usually needs company tax IDs, not just personal ones — or non-Spanish IBANs.
• The validation result is regulator-facing, auditable, or contractual. Near-zero adoption means no support contract, no security-review history, no CVE track record. For audited flows, build in-house with tests you control, or choose a maintained, better-adopted alternative.
• Your runtime is behind: the package tracks modern PHP and Symfony (Symfony 7/8, PHP 8.4/8.5 support, PHP 8.1 dropped). Verify version resolution in the target app before committing.
• You want a dependency with community depth. One maintainer, no issue activity, no visible dependents means you are, in practice, the only user.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed PHP library that validates the Spanish identifiers we will need the moment Spanish customers or suppliers come onto the platform — national ID numbers (DNI/NIE), Spanish bank account codes (CCC), and Spanish IBANs. It saves roughly a sprint of engineering and removes a blocking dependency from any Spain-facing item on the roadmap. Cost is effectively zero, the surface area is tiny, and replacing it later is a contained change, so downside is limited. The caveat to state up front, in writing: it confirms an identifier is well-formed, not that it is real. Actual identity verification stays with our KYC vendor. Setting that expectation now protects us with sales, compliance, and customers.

To engineering: One interface, one method — instantiate a validator, call isValid($value). No Laravel integration ships out of the box: no Rule classes, no validation messages, no FormRequest support, so that work is ours and is genuinely small (one wrapper rule per code type, plus error strings and tests). It is stateless, dependency-free, and free at runtime, so there is no performance or scaling concern. Three things to settle before we start: (1) wrap it behind our own validation layer rather than calling it from controllers, so a future swap is a one-file change; (2) pin the version and add our own test vectors for known-good and known-bad DNI/NIE/CCC/IBAN values — the repo shows CI, but we should not assume edge-case coverage we have not verified ourselves; and (3) confirm PHP/Laravel version resolution in the target app first. Known functional gaps to design around: no CIF/NIF, no international IBANs, no existence checks, and a single-maintainer upstream with a documented fork fallback.