Product Decisions This Supports
- Feature prioritization for bot/abuse protection: The addition of a Math Captcha gives the PM a second verification mode alongside whatever image/text-based challenge already exists. This directly supports decisions about onboarding friction: math challenges are typically easier for humans on mobile and do not depend on image assets or third-party services, so they can be the default for low-risk forms (newsletter signup, comment submission, password reset) while heavier challenges remain on high-risk surfaces (checkout, account creation).
- Roadmap for accessibility and localization: Math Captchas are language-agnostic once numerals are rendered and are generally more screen-reader-friendly than distorted-image CAPTCHAs. This supports an accessibility compliance workstream (WCAG) without needing to buy a separate vendor.
- Build vs. buy on bot mitigation: Adding a challenge type inside an existing Laravel package is far cheaper than integrating and paying for a hosted provider (reCAPTCHA Enterprise, hCaptcha, Turnstile). This release supports a “stay in-house / stay self-hosted” decision if your threat model is commodity spam bots rather than targeted abuse.
- Use cases enabled: configurable per-route challenge type, A/B testing challenge modes to measure conversion impact of verification friction, and internal admin/back-office forms where you want a lightweight check with no external network dependency or data-sharing agreement.
- Risk-reduction decision: a dependency-free challenge option reduces exposure to third-party outages and privacy review overhead (no user data sent to Google/Cloudflare). This is a meaningful input to vendor-risk and procurement discussions.
When to Consider This Package
Consider adopting (or keeping) this package when:
- You are on a supported Laravel version and want captcha/verification wired through Laravel’s native validation, config, and Blade rather than hand-rolling a challenge.
- You need multiple challenge types behind one interface — the new Math Captcha means you can pick per form rather than standardizing on one mechanism.
- Your abuse profile is commodity spam (scrapers, credential-stuffing scripts, form-fill bots) rather than sophisticated, human-assisted or ML-driven attacks. Math challenges are cheap to solve programmatically and should not be treated as strong anti-automation.
- You want self-hosted, no-external-call verification for privacy-sensitive flows or air-gapped/internal deployments.
- You value low operational surface: no API keys, no vendor billing, no outbound network dependency.
Look elsewhere when:
- You need enterprise-grade bot defense (behavioral scoring, device fingerprinting, risk APIs). Prefer Turnstile/hCaptcha/reCAPTCHA Enterprise or a WAF/bot-management layer.
- You are protecting high-value transactions where a math prompt is trivially bypassed and would create a false sense of security.
- The package’s release hygiene is a concern. Note on this release: “Add Math Captcha” is a new capability shipped in a patch version (3.1.1), which signals non-strict semver. For a PM this matters: pinning to
~3.1.0 will silently pull in new behavior; downstream teams should pin exactly and review changelogs. It also suggests the project does not maintain a published deprecation/support policy you can rely on for long-term roadmaps.
- Maintenance signals look thin (single-maintainer, low release cadence, no security policy). Request the repo’s issue throughput, last-commit date, and CVE history before committing.
Adoption criteria checklist: supported Laravel/PHP matrix confirmed, config published and cache-safe, validation rule integrates with Form Requests, challenge is testable (bypass/disable in test env), no outbound calls, and a documented escape hatch so you can swap challenge providers later.
How to Pitch It (Stakeholders)
For executives (one paragraph): This release adds a Math Captcha as an additional, self-hosted bot-verification option in our existing Laravel package. It lets us reduce form spam on low-risk surfaces with zero vendor cost, no outbound data sharing, and no new privacy review — while keeping stronger protection where it matters. It is a small, low-risk capability that improves our options for accessibility and localization. The caveat: it is a feature shipped in a patch release, so we should pin the version and avoid treating math challenges as sufficient protection for high-value flows.
For engineering (summary): New challenge type available through the package’s existing config/validation path; expected to be selected per form rather than globally. Two things to action in the upgrade: (1) semver discipline is loose — pin exact versions and read diffs, since a feature landed in a patch; (2) confirm the math challenge is disabled or deterministic in the test suite and that no session/cache keys collide with existing challenge types. Recommend evaluating it as the default for low-risk forms only, with a documented path to a managed bot-defense provider if abuse escalates.