Comments URL: https://news.ycombinator.com/item?id=47528281

Points: 3

# Comments: 0

The service is intentionally narrow. Destinations/config are stored encrypted, submissions are treated as pass-through, there is no persistent message storage at all. The idea is to reduce both retained data and attack surface as much as possible.

On reliability: yes, this is still a third-party dependency in the submission path. So if someone wants absolute control or is dealing with very sensitive data, I’d still say a self-built endpoint is the better choice.

This is really meant for the middle ground: people who want spam protection + delivery handling without maintaining the whole thing themselves.

The idea is simple: point any HTML form at the API, and it blocks spam invisibly, delivers submissions straight to your email or webhook, and stores nothing.

I built it because I kept running into the same tradeoff with forms on websites and client projects: the simpler tools were fast but limiting, while the more advanced ones often came with dashboards, stored submissions, more complexity, and more overhead than I actually wanted.

What I wanted was something closer to: - invisible spam blocking - no CAPTCHA for visitors - email and webhook delivery - simple integration with HTML forms - no dashboard required - less privacy/GDPR overhead

So that's what I built. There’s a free tier as well.

Would love feedback, especially from people building websites, client projects, or lightweight products. Curious whether this "barebones vs bloated platform" gap is something others have run into too.

Comments URL: https://news.ycombinator.com/item?id=47273579

Points: 1

# Comments: 3

Comments URL: https://news.ycombinator.com/item?id=45886702

Points: 1

# Comments: 0