I spent years inside web automation — building the kind of systems SpamKill now stops. SpamKill isn't a product I researched into existence. It's a product I built because I already knew exactly where the bots break.
Before SpamKill, I spent years as a freelance engineer working across the parts of the web most people never look at. HTML, CSS, JavaScript at the surface. Underneath that, the things that actually decide whether a page can be scraped, automated, or impersonated: obfuscation, encryption, browser fingerprinting, network behavior, and a long list of programming languages picked up across client work.
A meaningful chunk of that work was web automation — building the systems that submit forms, click through funnels, and move data through other people's sites at scale. That isn't the part of the résumé you put on a billboard, but it's the part that matters here. I know how form automation works because I've written the other half of it.
One day I was reading a social-media group full of small business owners venting about their day-to-day. The same complaint kept showing up: form spam. Fake leads, junk submissions, mornings lost to deleting garbage out of inboxes. People had tried CAPTCHAs, content filters, plugin after plugin — and the bots kept coming.
And reading it, I realized something almost embarrassing: I already knew how to fix this. Not in theory. In code. The exact tricks the bots were using to look human were tricks I'd worked with from the other side. There was a way — a way that didn't involve punishing real people with puzzles, didn't rely on blocklists, didn't depend on guessing what "spammy" content looked like.
I reached out to one of the business owners in the thread and convinced them to let me try it on their forms. The solution worked. Then it worked for a second customer. Then a tenth. I had paying clients before SpamKill even had a name. It wasn't born from a brand exercise or a pitch deck — it was born as a working defense built for one frustrated user, and the name showed up much later, after the product had already proven itself in the wild.
That's the entire edge. Form spam is an arms race, and arms races are won by whichever side understands the other side's tools at the engineering level. Studying bots from the outside gets you yesterday's signatures. Building bots gets you tomorrow's evasion paths.
SpamKill exists because one person sat in a Facebook thread, saw a problem he'd already solved in a different context, and decided to put it in front of someone who needed it. Everything since then — the customers, the infrastructure, the integrations, the team — grew out of that single conversation.
Not a hiring list — the actual things that show up in product decisions every week.
Years of freelance work building systems that drive browsers, submit forms, and move through funnels at scale. The exact techniques SpamKill is designed to detect.
Hands-on experience hiding logic from automated readers — and reverse-engineering the same tricks when they show up elsewhere. SpamKill's form transformation layer comes directly from this.
How requests actually look on the wire, how browser fingerprints get spoofed, where behavioral signals leak even when content looks identical. The detection model is built around these gaps.
Form fields, event timing, DOM mutation, the parts of the spec that automated systems handle differently than humans. Every defense in SpamKill compiles down to one of these.
A long list of languages picked up across client work. Useful when an integration needs a quick adapter, a customer's stack is unusual, or a piece of detection has to run somewhere unexpected.
SpamKill started as a one-person experiment built directly for one frustrated user. That conversation is still how product decisions get made.
Bot defense doesn't fail in marketing decks. It fails at 2am, on a single customer's checkout, when a new evasion technique shows up in the wild. Here's what that looks like at SpamKill:
When a real customer issue lands, it doesn't get triaged by a script. The founder reads it. Often replies to it. Sometimes patches it the same day.
The person writing detection logic and the person you talk to about an outage are the same person. There is no second loop.
Most evasion techniques aren't a surprise here. They're variants of things that were already familiar from years of web automation work.
Every integration, every quarantine flow, every dashboard decision started with a real customer asking for it — not a quarterly planning meeting.
Whether you're evaluating SpamKill for a complex stack, debugging an integration, or just want to dig into how form bots actually work — I read every email.