Akismet Laravel Package

Product Decisions This Supports

• Opening up public, unauthenticated form surfaces. Contact forms, guest posts, event/job submissions, reviews, and directory listings are the highest-spam-risk surfaces in a Statamic build. This package lets you ship those features with a defensible spam posture instead of blocking them behind CAPTCHA or login.
• Choosing a moderation model. It makes "flag as spam and queue for review" a config-level decision rather than a custom build — auto-reject, quarantine, and human-review workflows all become cheap to prototype. That determines whether you staff a moderation rota or not.
• Build vs. buy for spam defense. Buy side: Akismet is a paid, hosted, mature classifier with a known cost curve. Build side: honeypot fields, rate limiting, Turnstile/hCaptcha, and custom heuristics. This package is the cheapest possible "buy" path if you're already on Statamic — it collapses the integration to a composer require plus an API key.
• Roadmap sequencing for community/UGC features. If community features are on the roadmap, spam handling is a prerequisite, not a nice-to-have. Adopting this now de-risks the roadmap item; skipping it means either delaying UGC or accepting a manual-moderation tax.
• Trust & safety posture and content risk. Spam on public pages is a brand and SEO liability (link-injection, toxic content). This gives you a recognized vendor's verdict on every payload without owning an ML pipeline.
• Vendor and platform lock-in surface. Adoption explicitly ties you to two things: Statamic (the addon is Statamic-only, not generic Laravel) and Automattic's Akismet service. That's a real architectural commitment worth naming in the decision record.

When to Consider This Package

Consider it when:

• You are running Statamic (v4/v5) — this is not a general Laravel package and offers nothing to a plain Laravel app.
• You already have, or are willing to buy, an Akismet subscription (paid tiers start cheap for low volume; check current pricing against your form-submission volume).
• Your spam vector is form submissions, not scraping, credential stuffing, or API abuse — Akismet is a content classifier, not a WAF.
• You have no dedicated trust & safety capacity and want moderation to be an exception-handling workflow rather than a full-time job.
• You want the integration to be configuration, not code — fewer bespoke lines to maintain, easier handover.

Look elsewhere when:

• You're on plain Laravel — use a general Akismet client, a honeypot/rate-limit combination, or a managed bot-defense provider instead.
• You need enterprise assurances: the adoption signals here are thin (single-digit stars, zero dependents, single-maintainer profile). There is no support contract, no SLA, and a real bus-factor risk. Budget for vendoring or forking if the feature becomes load-bearing.
• You have privacy/GDPR constraints that make shipping user-submitted content to a third-party classifier unacceptable without a DPA review.
• You need high-volume or adversarial-grade filtering — layer in rate limiting, Turnstile, and log-based heuristics regardless.
• You require self-hosted or offline detection.

Diligence before adopting: verify Statamic version compatibility and tag history first — the recorded latest-release date looks like a metadata artifact, so confirm actual commit cadence. Then pin the version, wrap the spam check behind your own thin interface, and keep a documented fallback (honeypot + rate limit) so a stalled upstream doesn't block a release.

How to Pitch It (Stakeholders)

For executives: We can enable public submissions — community posts, reviews, guest content — without adding friction like CAPTCHA or login walls, and without hiring moderators. This addon plugs our CMS into Akismet, an established spam-filtering service, so every submission gets scored automatically and the obvious junk never reaches a human. Cost is a small monthly API fee plus roughly a day of engineering; the alternative is either building and maintaining our own filtering or permanently staffing review. The tradeoff to accept consciously: it's a small, single-maintainer open-source component, so we treat it as a tactical dependency with a documented fallback rather than core infrastructure.

For engineering: One composer require, publish config, put the Akismet key in the environment, and wire the handler into Statamic's form submission lifecycle — no schema changes, no background workers. The important ask is that we don't call the package directly from form handlers: put a SpamCheck contract in front of it so swapping in a different provider, or a local honeypot/rate-limit strategy, is a one-class change. Also confirm compatibility against our Statamic version and pin the tag, since upstream release activity is hard to verify from the metadata.