Captcha Laravel Package

Product Decisions This Supports

• Build vs. buy for bot/abuse protection. This package lets us self-host a captcha challenge inside an existing Laravel app instead of signing up for a managed vendor (reCAPTCHA, hCaptcha, Cloudflare Turnstile). The trade-off to weigh is vendor risk scoring and zero-maintenance vs. keeping user data in-house, avoiding third-party JS calls, and avoiding per-request cost.
• Roadmap for public-facing forms. Relevant to signup, login, password reset, contact, newsletter, and comment surfaces. A minor-version Laravel package is a small, PR-sized integration — it can ship as a hardening item in an existing sprint rather than a standalone roadmap initiative.
• Feature gating without vendor consent flows. Useful where third-party captcha scripts are undesirable: internal admin tools, regulated environments where PII can't be sent to a third party, or regions where Google-hosted assets are unreliable or blocked.
• Success metrics to instrument. Spam/abuse submission rate before vs. after, form completion drop-off, and support-ticket volume for "I can't read the characters." Captcha is a conversion-tax feature — the PM should own the friction number, not just the spam number.
• Accessibility and compliance posture. Image-based challenges carry well-known WCAG friction. Any adoption decision needs an explicit answer on audio/alternative modes and on jurisdiction-specific accessibility obligations.

When to Consider This Package

Adopt when:

• The product is a Laravel application already using the framework's validation and session layers, and you want a challenge that drops in with a service provider, published config, and a validation rule.
• Abuse volume is low-to-moderate and the protected surfaces are low-value (contact forms, newsletter signup, comment spam).
• You want no outbound network dependency, no third-party data processing agreement, and no per-request billing.

Look elsewhere when:

• Abuse is high-volume or financially motivated (credential stuffing, account takeover, scalping, promo abuse). Image captchas are weak against modern solver farms; use a managed risk-scoring service instead.
• You need native mobile/API protection, invisible challenges, or device fingerprinting — outside this package's remit.
• Accessibility is a hard requirement without an acceptable fallback path.
• Maintainership fails due diligence. The v2.1.0 release notes are only a changelog compare link — no described features, fixes, or deprecations. Before adopting, review the actual commit diff, the Laravel version support matrix, test coverage, issue responsiveness, and release cadence. An uninformative changelog is a process signal, not a blocker, but it shifts the burden of proof onto us: pin the version and read the diff. Confirm the package's scope (self-hosted image challenge vs. a wrapper around a third-party provider) against the repo before assuming capabilities.

How to Pitch It (Stakeholders)

To executives: This is a free, self-hosted way to slow down automated abuse on public forms. No vendor contract, no per-request cost, and no user data leaving our infrastructure — a meaningful compliance and privacy advantage over Google-hosted captchas. The honest caveat: it is a speed bump, not a bot-management platform. It's the right call for low-risk forms; if we see organised or financially motivated abuse, we should expect to graduate to a managed service. There's also an accessibility risk to accept or mitigate. Recommend a scoped pilot on one or two low-risk forms rather than a platform-wide commitment.

To engineering: Small surface area — Laravel service provider, publishable config, a Blade-rendered challenge, and a validation rule backed by the session. Fits existing patterns; expect a small PR plus tests. Two asks before merge: review the v2.1.0 diff directly (release notes were empty) and confirm Laravel/PHP version support for our stack. Pin the version and track upstream activity.