DEV Community: Sifat Ahmed

A counting-stat animation in HyperFrames, full working code (free recipe)

Sifat Ahmed — Sun, 06 Sep 2026 05:33:01 +0000

Following up on the guide I posted about a couple days ago (HyperFrames — renders video from plain HTML/CSS/GSAP instead of a timeline editor). Here's one full recipe from it, in full, free — no teaser cut-off.

The pattern

Turning a plain number into a small performance reads as far more "designed" than just displaying a static figure — genuinely effective for anything results/data-driven: a metric, a price, a countdown.

<section class="clip" data-start="0" data-duration="3" data-track-index="1">
  <div id="stat">0</div>
  <p>customers served</p>
</section>

const counter = { value: 0 };
tl.to(counter, {
  value: 12480,
  duration: 1.6,
  ease: "power1.inOut",
  onUpdate: () => {
    const el = document.getElementById("stat");
    el.textContent = Math.round(counter.value).toLocaleString();
  }
}, 0.2);

Why it's built this way

Tweening a plain JS object (not the DOM element itself) and writing the formatted number into the element on every tick is the reliable way to do this in a render pipeline that has to seek to arbitrary timestamps and always get the same pixels. It stays perfectly deterministic — the exact displayed number at any timestamp is a pure function of that timestamp — and it avoids animating a text property GSAP doesn't natively tween.

This is one of six recipes in the full guide (title reveal, logo intro, scene crossfade, CTA morph, Ken Burns background drift are the other five), plus a "five pitfalls" section on the mistakes that produce a blank render or frozen frame instead of a helpful error message. If the rest is useful: https://sidheart.gumroad.com/l/lyudd ($19).

Happy to answer questions about the pattern itself here for free either way.

Made a paid guide from an open-source Claude skill (without reselling it)

Sifat Ahmed — Sun, 06 Sep 2026 05:10:26 +0000

Quick build-in-public post, same vein as my earlier n8n automation service posts.

I wanted to package something adjacent to that work: a guide to HyperFrames, an open-source framework (from HeyGen) that renders video from plain HTML/CSS/GSAP instead of a timeline editor. There's a Claude Code skill that teaches an AI agent this framework - genuinely useful, but not something I built, so selling a copy of it would've been selling someone else's open-source work as my own.

What I did instead: wrote an original guide teaching the technique - the actual mental model (why the render has to be deterministic and seekable, and what that means for how you write animation code), plus six complete working recipes (title reveals, counting stats, crossfades, that kind of thing) with real code, checked against the framework's actual contract rather than simplified examples that fall apart the moment you try to render them for real. Same rule paid Docker/React courses run on: the tool itself is free, the technique you package around it is legitimately yours to sell.

$19 on Gumroad if it's useful to anyone building video-from-code pipelines: https://sidheart.gumroad.com/l/lyudd

Happy to answer anything about HyperFrames or the deterministic-rendering mental model if useful - not trying to oversell it, just sharing what I built.

OpenAI Shipped a Hard Spend Limit - Here's the Gap It Still Leaves Open

Sifat Ahmed — Fri, 04 Sep 2026 04:32:03 +0000

For most of 2026, this was true: OpenAI's budget field was alert-only. Cross your number, get an email, keep getting billed. That changed on July 23, when OpenAI rolled out real hard spend limits to every API account, free, no enterprise tier required. Set a cap at the org or project level, and once tracked spend reaches it, further requests fail with a 429 until the next billing cycle.

That's a genuine fix for the worst version of this problem - a leaked key or a runaway retry loop can no longer bill you into the ground forever. If you haven't turned it on, it's worth doing today: project settings, Limits, Edit spend limit, done in two minutes.

But a few weeks of watching this land tells me it doesn't close the gap most solo devs actually have. Two things stayed true even after the feature shipped.

It's a kill switch, not a warning

OpenAI's own guidance is to only use hard limits on dev/CI keys, not production - because the cutoff is account-wide and immediate. It doesn't stop the one customer or workflow that's spending; it stops everything behind that key. For a side project that's fine. For anything with real users hitting it, flipping that switch on means a runaway loop doesn't just cost you money anymore, it takes your app down completely, with no warning first.

So the same developers this feature was built for mostly end up leaving it off in production, for the same reason they left the old alert-only budget too high to matter: the downside of it firing is worse than the upside of it existing. That's not a flaw in OpenAI's implementation - a blunt, request-blocking cap has to work that way. It just means "OpenAI now has a hard limit" and "I can safely turn it on" are two different sentences.

A cap tells you after, not before

Even set up correctly, a hard limit is silent until it fires. You don't get a "hey, you're at 80%, might want to look" - you get a working app, then a 429. The dashboard shows you the number if you go check it, but nothing pushes a signal to you before the wall.

That's the part I built Fusebox around originally, and it's still true regardless of whether the hard limit exists: Fusebox watches your usage against a ceiling you set and emails you at 50%, 80%, and 100% of it, using a read-only Admin key scoped to api.usage.read - it can see your numbers, it can't spend or touch your account. Free tier emails you once you're over. Paid ($7/mo) adds the earlier warnings, which is the part that actually lets you catch a loop while it's still cheap to fix.

The honest way to put it: OpenAI's hard limit is the backstop you hope you never need. Fusebox is the thing that tells you early enough that you never do.

If you've turned on OpenAI's hard limit in production, I'd like to know - did you actually leave it on, or did the account-wide blast radius talk you out of it? That's the real open question this feature raised for me.

Bot protection and unsubscribe: the two features I built before Fusebox had a single user

Sifat Ahmed — Sat, 29 Aug 2026 16:02:07 +0000

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.

I'm running a done-for-you automation service on self-hosted n8n — looking for a first pilot client

Sifat Ahmed — Sun, 23 Aug 2026 11:08:03 +0000

Quick build-in-public post. I've been setting up a small service: I build and run n8n automations for people — the repetitive stuff that eats an hour a day (copying data between tools, replying to the same kind of message, chasing follow-ups) — self-hosted on my own infrastructure, so you never touch the software or pay for a seat. You just get the automation working.

Stack is self-hosted n8n + Postgres, monitored (I run my own uptime checks on it so I know before you do if something's down), fronted through Cloudflare. Zero infra cost on my end at this stage, so pricing stays honest rather than padded to cover a cloud bill.

I'm looking for a first real pilot — something small and concrete (a workflow you're doing by hand right now that shouldn't need to be). I'll build it free or heavily discounted in exchange for honest feedback and, if it goes well, a testimonial. Not trying to oversell this: it's early, I have zero client track record yet, and I'd rather say that upfront than pretend otherwise.

If you've got something repetitive eating your time, or you know someone who does, I'd genuinely like to hear about it — reply here or DM.

Why Fusebox doesn't support Claude yet

Sifat Ahmed — Sun, 23 Aug 2026 02:50:06 +0000

Fusebox emails you before your OpenAI bill blows past a number you set. Before writing any of that code, I spent an afternoon checking one thing: what kind of API key would I actually need to ask people for?

That question mattered more than it sounds like it should. A tool that reads your spend needs some credential from your account. The honest version of that credential can only read - it can't touch billing, can't create or revoke other keys, can't add or remove people from your org. The dishonest version asks for more than it needs and hopes you don't check.

OpenAI: genuinely scoped

OpenAI lets you create an Admin key and restrict it to specific permissions per resource - None, Read, or Write. For usage and cost data specifically, that's a scope called api.usage.read. Grant only that, and the key can pull your spend numbers and do nothing else. That's exactly the shape of trust a tool like this should ask for.

Anthropic: not yet, for individual accounts

I checked the same thing for Claude, expecting a similar scoped option. Anthropic's own docs say otherwise, for Claude Console (the product individual developers actually use):

"Claude Console keys do not have selectable scopes; every key carries full access to all endpoints that accept Admin API keys."

Scoped read-only keys do exist on Anthropic's side (read:spend_limits, read:analytics) but only for Claude Enterprise organizations, not individual Console accounts. For everyone else, the only key that can read usage data can also manage your organization's members and revoke other people's API keys.

Asking a solo developer to hand that over, in service of a feature as small as "email me at 80% of my budget," is a bad trade. So Fusebox doesn't do it yet. Claude support is built and waiting - it's a small amount of code - but it stays off until Anthropic ships the same kind of scoping for individual accounts that OpenAI already has.

Why this is worth writing down

Most tools that ask for API access don't explain what they're actually asking for, and most users don't check. I'd rather the constraint be visible than quietly worked around.

Fusebox is free, early access, OpenAI-only for now: https://fusebox.sifatsrk.workers.dev

If you've found a cleaner way to do the Claude side of this safely, I'd genuinely like to hear about it in the comments.