No Captcha Laravel Package

Product Decisions This Supports

• Feature: abuse mitigation on public forms. Signup, login, password reset, contact, checkout, and comment forms all attract bot traffic. This package lets engineering add Google reCAPTCHA (v2 checkbox, v2 invisible, and v3 score-based) to a Laravel form in a few lines — a config file, a Blade directive, and a validation rule — so the PM decision is "do we need a bot gate on this form?" rather than "how much engineering does it cost?"
• Build vs. buy (vs. reuse). The alternative is writing your own reCAPTCHA client, config, and Laravel validation wiring — a day or two of work plus ongoing maintenance. This is MIT-licensed and already wraps that plumbing, so the comparison is really this package vs. a maintained alternative (Cloudflare Turnstile, hCaptcha) vs. building in-house. Treat it as a low-cost reuse option, not a strategic platform bet.
• Roadmap sequencing. Because the integration surface is small and reversible, it's a good candidate for a near-term hardening sprint alongside rate limiting and honeypot fields, rather than a multi-quarter initiative. It also unblocks gating a new high-traffic landing page or self-serve signup flow without a design-heavy CAPTCHA UX debate.
• Risk appetite per surface. reCAPTCHA v3 is score-based and invisible, which suits conversion-sensitive funnels; v2 checkbox is more visible friction, which suits lower-value abuse-prone endpoints. That's a per-form product trade-off (friction vs. false-positive tolerance) this package supports directly.
• Compliance and vendor decisions. Adopting it commits you to sending user signals to Google. That's a product/legal decision about third-party data flows (GDPR/CCPA notices, cookie consent, enterprise procurement in some regions), not just an engineering one — and it should be surfaced early if you serve EU or regulated users.

When to Consider This Package

Reasonable fit when:

• The product is a Laravel application and the team wants reCAPTCHA specifically (existing Google Cloud account, no appetite for a new vendor).
• You need a fast, low-effort bot gate on a handful of forms, and standard server-side validation is enough.
• You accept Google as a subprocessor or operate in a context where that's already the case (e.g., Google Analytics/Sign-in already in place).
• You're doing a spike or MVP where speed matters and a swap later is cheap.

Look elsewhere or plan a replacement when:

• Maintenance risk matters. The last release is 2022-02-10, and the dependent count shown is zero. Before committing, verify it installs and passes tests on your current Laravel and PHP versions, and that the maintainer is responsive. If your support policy requires actively maintained dependencies, budget for a fork or a swap.
• You need vendor neutrality or a free/low-friction alternative. Cloudflare Turnstile and hCaptcha are common substitutes with different privacy postures; Turnstile in particular avoids Google entirely and is often a smoother consent story.
• The application isn't Laravel/PHP, or you need a first-class mobile SDK rather than server-side validation.
• Privacy-sensitive or regulated user base where sending behavioral signals to Google requires consent work or is contractually disallowed.
• Accessibility is a hard requirement with no tolerance for friction — CAPTCHAs broadly struggle here; a honeypot plus rate limiting plus risk scoring may be the better product answer.
• You need advanced controls: per-form score thresholds, fallback challenges, or analytics on challenge pass/fail rates beyond what the vendor console gives you.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can harden our public-facing forms against bot signups and spam in roughly a day of engineering by adopting an existing, MIT-licensed Laravel integration for Google reCAPTCHA. There is no license cost and no new infrastructure; the trade-off is that we send some user signals to Google, which we should confirm is consistent with our privacy policy and any regional requirements. The main caveat is that the package hasn't had a release since early 2022, so the recommendation is to adopt it behind a small due-diligence check — verify it works on our current stack and be prepared to swap to a maintained alternative (Cloudflare Turnstile or hCaptcha) if it doesn't. Because the integration is thin and reversible, this is a low-risk decision we can make quickly rather than a platform commitment.

For engineering: It's a thin wrapper — publishable config, Blade directive, and a Laravel validation rule for v2 checkbox, v2 invisible, and v3. No schema changes, no queue or background work. The real work items are: confirm compatible Laravel/PHP versions given the 2022 release, pin the dependency and add the form endpoints to our smoke tests, choose v3 score thresholds per form, and make sure failure handling degrades gracefully (fallback to email verification or rate limiting rather than a hard block). Please also flag the keys as secrets in the environment config, not in source.

For design/UX: Default to v3 or invisible where conversion matters, and reserve the visible checkbox for low-intent endpoints. Plan the error state — "we couldn't verify you're human" needs a retry path that doesn't dead-end the user.