Sendtric

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me a countdown timer for email that replaces Sendtric: an image URL that shows the time remaining at the moment the message is opened.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3 for the timer definitions and the render log
- sharp or a GIF encoder for the frames; no browser, because this must be fast
- Caddy in front, and ideally a CDN in front of that

WHY THIS EXISTS AT ALL
- Email clients run no scripts. The only way to show a live number is an image generated when the client fetches it
- So the entire product is one endpoint that returns a picture, and the entire engineering problem is that the picture must arrive very quickly and be small

THE DATA MODEL
- timers: id, slug, name, ends_at_utc, timezone_note, style_json, width, height, kind, expired_kind, expired_text, expired_image_path, created_by, created_at
- renders: id, timer_id, at, ip_hash, user_agent_bucket, referrer, ms, bytes, cache_hit, is_prefetch
- Renders are recorded because the fetch of a countdown image is a strong open signal — but read the honest note below before treating it as one

THE RENDERING, WHICH IS THE WHOLE CRAFT
- Animated GIF, because it is the only animated format every mail client renders. Not WebP, not APNG, not video
- The GIF contains one frame per second for a bounded number of seconds — sixty is typical — and then stops. It cannot loop, because a looping countdown would run backwards
- After the last frame the image holds the final value. Somebody who leaves the message open sees a stopped clock, which is correct and expected
- Keep it small: a limited palette, only the digits changing between frames, and frame differencing so each subsequent frame carries almost nothing. Aim well under a hundred kilobytes — a heavy GIF on mobile data simply never appears
- Render the digits with a self-hosted font at the size given, with tabular figures so the layout does not jitter as numbers change
- Pre-render the static background once per timer and composite only the digits per frame
- The whole response must be produced in tens of milliseconds. Mail clients give an image very little time before giving up

CACHING, CAREFULLY
- The image is different every second, so it cannot be cached for long — but it can be cached for exactly one second, which absorbs the burst when a send goes out to fifty thousand people at once
- Cache key: the timer plus the current second. Generate once, serve to everybody who arrives in that second
- Set headers that let a proxy cache for a second and no longer, and prevent any client from storing it
- Warm the cache for the seconds around a scheduled send if you know when it is

WHEN IT ENDS
- Configurable: a static expired image, a message, or a redirect to a different image
- Never a broken image and never a negative number
- The end time is a fixed instant in UTC. A per-recipient countdown — 'twenty-four hours from when you opened this' — is possible with a token in the URL, but be aware it is a fake deadline unless you actually enforce it, and a fake deadline is the thing that makes this whole category feel manipulative

THE HONEST PART, WHICH BELONGS IN THE README
- A countdown creates urgency, and urgency about a deadline that is real is persuasion while urgency about one that is not is a lie told with a clock on it. If the offer does not actually end, do not put a timer on it
- The image fetch is also an open signal, subject to every caveat that applies to tracking pixels: privacy proxies pre-fetch images, so a large share of renders are machines, and readers with images off see nothing at all. Treat the render count as a very loose lower bound and label it as one

THE INTERFACE
- Create a timer: end time with a zone, size, colours, font size, labels, and whether to show days
- A live preview showing the real rendered GIF, not a simulation
- The URL to paste, and an HTML snippet with the image wrapped in a link and an alt text that says something sensible for the clients that will not load it
- Alt text matters: a message whose only urgency is in a blocked image says nothing at all

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, FONT_PATH, MAX_FRAMES, HASH_SALT
- Migrations on boot, each once
- Behind a CDN if the sends are large; the origin should see one request per timer per second
- A rate limit per address hash to stop the endpoint being used as a general image farm
- Health endpoint that renders one frame

WHAT MATTERS MOST
Speed and file size. Get a full GIF generated and served in tens of milliseconds and well under a hundred kilobytes, then send a test to yourself on a phone over mobile data and watch whether it appears before you have finished reading the message.

Give me the repository, the renderer, migrations, .env.example, the HTML snippet, and a README with deploy steps, the caching headers, and the note about real deadlines.