The contact form on a static marketing site is a public inbox with no built-in filter. Bots find the endpoint. Your notification fires. You open the message and realize—again—that nobody human wrote it.
Whatever backend you use to collect submissions probably has some spam detection. Messages still get sent. You still pay the latency, the webhook noise, and the operator attention tax of deciding what to delete. The question that stuck: how do you prevent junk from being submitted at all, in a way a solo maintainer can adopt without a quarter of API plumbing?
That question became Spamblock—a product MWWE ships end to end, documented in our Spamblock case study. This post is the why behind it.
Spam that reaches the inbox anyway
I have been interested for a long time in using technology to make the world a bit better. The last few years have also made one trend impossible to ignore: fraudulent and abusive activity on the internet is up. AI and modern tooling enable wonderful things; they also lower the cost for bad actors to spray forms, inboxes, and marketplaces at scale.
I maintain many websites and work with clients who run public forms on theirs. The pattern repeats: legitimate inquiries mixed with a huge volume of automated submissions, regardless of which form backend sits behind the HTML. Filtering at the destination helps—but it treats spam as inevitable mail you sort later. Spamblock treats it as something you can challenge earlier, with minimal setup.
Marketplaces and legacy tools
A lot of my professional background is enterprise software and marketplace trust-and-safety—companies like trivago, eBay, Kijiji, and AutoTrader, where threat detection is not an optional module. I also cofounded a startup aimed at revolutionizing and simplifying fraud-detection tooling for businesses.
That work teaches you what enterprise anti-abuse looks like: powerful, often cumbersome, built for teams with dedicated analysts and long integration cycles. Most small sites do not need that footprint. They need good enough protection that does not require deep technical acumen just to connect APIs and keep a scoring pipeline alive.
Score at the browser, not the inbox
Spamblock’s core idea is deliberately simple: a copy-paste frontend pixel in the <head> of any HTML page.
The script auto-detects forms and submissions on the page. Before a submission goes out, it analyzes the data being sent plus signals about the entity submitting it, then adds threat scoring and rationale to the form payload. Your backend—or Spamblock’s hosted form service—can use those fields to decide what to keep, quarantine, or drop. You are not guessing from raw text alone; you get structured context at the edge.
That model fits static sites especially well: Cloudflare Pages, Eleventy, hand-rolled HTML—places where “install our SDK and refactor your stack” is a non-starter. The integration stays a snippet, not a platform migration. MWWE’s portfolio write-up covers deployment posture and operator workflows for teams adopting the layer without overbuilding around it.
Open-source pixel, hosted backend
Spamblock ships in two layers:
Open-source spam pixel (free) — the browser-side scoring snippet, already used across many production sites. It improves over time as it learns modern spam patterns from real-world traffic—not a frozen rules file from 2019.
Hosted form backend — for teams that want Spamblock to run the submission endpoint too. There is a generous free tier, plus business and enterprise options that stay feature- and cost-competitive for larger organizations. The backend adds further spam and fraud detection so operators can focus on business instead of playing whack-a-mole in their inboxes.
Same philosophy in both: reduce harm without adopting a full ticketing or CRM platform just to get a contact form under control.
Built for sites you actually run
MWWE built Spamblock front to back and keeps pushing on practical ways to deploy technology that reduces harm in the digital era—not slide-deck “AI safety,” but fewer fraudulent messages hitting humans who never signed up to be abuse analysts.
If your stack looks like the sites in our portfolio—static-first, form-backed, maintained by people who run more than one property—Spamblock is meant for you. Start with the pixel on an existing form, or route submissions through the hosted service if you want the full path with less backend work.
Explore the product at spamblock.io, read the case study, or contact MWWE if you want help rolling it out across client sites.