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.
I've been a freelance software engineer since I was in school — long enough to remember when most platforms had no APIs and Zapier didn't exist. Back then, if a client needed data moved between two systems — a CRM on one side, an order platform or a web form on the other — someone had to build the bridge by hand. More often than not, that bridge was web automation: an invisible but essential part of real client projects, quietly filling forms and ferrying data between platforms that were never designed to talk to each other.
Years of that work teach you the parts of the web most people never look at: obfuscation, encryption, browser fingerprinting, network behavior — and exactly what automated form interaction looks like from the engineering side. I know how form automation works because it was my day job for years.
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. Years of building web-automation integrations meant years of struggling with everything that makes a form hard to fill neatly through automation — every obstacle, every quirk, every dead end I'd had to engineer around, on platform after platform. I knew exactly what breaks automated form-filling, because it had been breaking mine for years. So I combined every one of those obstacles in one place and pointed them at the bots. That was version one — there have been a couple hundred revisions since. And it meant there was 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. Knowing what breaks automation gets you tomorrow's defenses.
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 obstacles already fought through in 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.