Fusebox emails you before your OpenAI bill blows past a number you set. Before writing that pitch anywhere, I built two things nobody asks for in a demo: a bot check on signup, and a real unsubscribe link. Neither was optional, and neither was hard - but skipping them is exactly the kind of thing a solo project quietly does when there's no user yet to complain.
Why bot protection on day one
The signup form asks for an OpenAI Admin key. That's the one part of Fusebox that can't be undone if it goes wrong - a scraped or brute-forced signup endpoint means someone else's key sitting encrypted in your database, or a flood of junk rows with no real owner. reCAPTCHA was the obvious default, but it ships a tracking script and a visible "I'm not a robot" checkbox that doesn't fit a tool whose whole pitch is "we ask for less than you'd expect." Cloudflare Turnstile does the same job - a managed challenge that mostly resolves invisibly - without the tracking baggage, and it's free.
The actual wiring is small: a widget on the client that calls back with a token once it resolves, a submit button that stays disabled until that token exists, and a server-side check against Cloudflare's own siteverify endpoint before the signup handler does anything else:
async function verifyTurnstile(token: string, secretKey: string): Promise<boolean> {
if (!token) return false;
const res = await fetch("https://challenges.cloudflare.com/turnstile/v0/siteverify", {
method: "POST",
headers: { "content-type": "application/json" },
body: JSON.stringify({ secret: secretKey, response: token }),
});
const data: any = await res.json().catch(() => ({}));
return data?.success === true;
}
If that check fails, the request never reaches the part that touches an API key or the database. One rule worth calling out: on any submit attempt - success or failure - the client resets the token and re-disables the button. A stale token from a previous attempt is exactly the kind of thing that gets missed until someone abuses it.
Why the unsubscribe link isn't a preference toggle
The simplest version of "let people leave" is a settings page with a checkbox. Fusebox doesn't have an account system at all - just an email, an encrypted key, and a ceiling - so there's no login to put a checkbox behind. The unsubscribe link that goes out with every threshold email carries a random token generated once at signup and stored next to that subscriber's row. Clicking it is a single GET that flips one column:
const result = await env.DB.prepare(
`UPDATE subscribers SET active = 0 WHERE unsubscribe_token = ? AND active = 1`,
).bind(token).run();
The AND active = 1 matters more than it looks. Without it, a link that's clicked twice - or forwarded, or hit by an email client's link-prefetcher - just re-runs the same update harmlessly. With it, the second click tells the truth: "already used," not a fake success. Small difference, but it's the kind of thing that's invisible right up until someone checks it, and getting it wrong is exactly the kind of bug that erodes trust in a tool whose entire pitch is trustworthiness.
Why write this down
Neither of these features is interesting on its own, and neither shows up in a screenshot or a pitch. They're the parts of a "trust us with your API key" tool that only matter when something goes wrong - a bot, a forwarded email, a link clicked twice - and by then it's too late to have skipped them. Building them before the first real signup, instead of after the first incident, was the point.
Fusebox is free, early access, live now: https://fusebox.sifatsrk.workers.dev
If you've built something similar and handled either of these differently, I'd like to hear about it in the comments.
