LAWRENCE_OS · GLASGOW · AVAILABLELAWRENCE_OS
--:--:--21%
← Home

RENDERD

Every AI video tool makes you feed it one job at a time — paste a prompt, pick your settings, hit go, wait, repeat. Fine for one clip. Miserable for thirty. And the tokens drain whether you're watching or not, so trial and error, which is basically the whole job, gets expensive fast.

Industry
AI tooling
Role
Solo: design + AI build
// the idea

RENDERD takes the queue off my hands: a local queue manager for image and video generation. I dump a batch of prompts into it — a blank line between each — attach reference images, set my defaults (model, duration, resolution), reorder by dragging, then start the worker and walk away. It submits jobs, respects the platform's concurrency limits, retries when a slot's busy, and tracks what's finished, all while I'm asleep or out or doing anything more useful than babysitting a browser. You come back to a folder of renders instead of a half-done afternoon.

RENDERD queue UI mid-run — 4 pending, 2 generating, 255 done; a column of image jobs with thumbnails, batch selection, and the prompt bar below
// the awkward part

The platform I use for video doesn't hand out an API for this, so RENDERD doesn't ask nicely — it drives the real web app. A background worker steers an actual Chrome window through my logged-in session, clicking the UI the way I would, on a stealth profile so Google OAuth doesn't clock it as a bot and lock me out. Log in once and the session sticks. One hack I'm oddly fond of: the platform kept moving its progress indicators around, so trusting the page to say when a render finished stopped working. Now it just does the maths — duration plus a few minutes of buffer, then move on. Less clever, far more reliable.

// architecture

The UI and the worker never talk directly. Everything goes through one SQLite file — the interface writes jobs in, the worker reads them out, and status flows back the same way. Kill either half and the other survives; restart and it carries on where it stopped.

renderd — process topologyno direct IPC
WRITES QUEUEREADS STATUS / HEARTBEATREADS / CLAIMS JOBSUPDATES STATUS / HEARTBEATDRIVESNext.js UIlocalhost:3000queue.db(SQLite)Worker loop(Playwright)Real Chromeapp.render3 PENDING · 3 RUNNING · 255 DONECLAIMING
JOB 0257 · RENDERINGsim loop
// economics

Tokens are the real constraint, and batching is where it paid for itself. The plan I was on ran about $100 a month; in one stretch I pushed 500+ Seedance 2.0 videos through it — roughly $900 of output at the platform's ~$1.80-a-clip pricing. Queuing tight batches with concurrency maxed drained a full plan's worth of value instead of a fraction of it. Nine times the output for the same spend, minus the afternoons.

renderd — one plan cycle511 clips
$0$250$500$750$1,000D01D10D20D30OUTPUT AT LIST (~$1.80/CLIP)PLAN SPEND ($100/MO)
// stack
Frontend
Next.js 14, React, TypeScript
UI
Tailwind, shadcn, dnd-kit
Worker
Node process, 5s poll loop
Automation
Playwright driving real Chrome, stealth profile
Data
SQLite (better-sqlite3)
Remote
Cloudflare tunnel
Packaging
Windows launcher, taskbar-pinnable
// result

Time back, mostly. I can line up a day of renders in a few minutes on my phone, tunnel into the machine at home, and collect the results later. The bottleneck stopped being me at a desk — the closest I've come to being in two places at once.

Seedance 2.0 clips, one plan
500+
vs ~$900 pay-as-you-go
$100
output for the same spend
~9×