[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f3mw482g2ee5wf":3},{"code":4,"message":5,"data":6,"timestamp":38},10000,"success",{"full_name":7,"position":8,"description":9,"language":10,"stars":11,"forks":12,"stars_gained":13,"age_days":14,"hn_threads":15,"one_liner":16,"summary_md":17,"topic":18,"github_topics":21,"license":34,"homepage":35,"updated_at":36,"history":37},"qianshuixia\u002Fshrimpreel",15,"Open-source template for \"one photo → AI video that follows a viral template\" SaaS sites, one site per trending keyword. Cloudflare Workers + D1\u002FR2\u002FKV\u002FQueues, TanStack Start + Hono, Google sign-in, credit packs (Waffo\u002FDodo), fal.ai video generation, admin console.","TypeScript",260,101,61,4,[],"A Cloudflare-native SaaS template for building a single-keyword photo-to-video site with auth, credits and payments already wired.","Adopt this if you want a working skeleton for a paid AI video site and are comfortable treating it as an unproven starting point: the author states the full flow passes local unit and Playwright tests but has not been deployed as a production site.\n\n## The problem\n\nSomeone with a trending photo-to-video format in mind usually starts by gluing together generation, login, credits and checkout before showing a single finished clip. The friction is the boring middle: keeping credit balances consistent, handling provider callbacks, refunding failed jobs and emailing customers. ShrimpReel replaces that middle with an existing template, so creating a site means forking the repository, changing config and copy, then pointing it at real payment and video providers. The result is a deployable site around one viral keyword rather than a prototype that needs its own billing and admin layer built from scratch.\n\n## What's different\n\nThe mechanism is a one-site-per-keyword model: each keyword site is its own repository tracking the template as `upstream`, so payment, security and framework fixes are made once and merged into every site. A sync-plan script and a bundled Claude Code skill (`.claude\u002Fskills\u002Fsync-upstream\u002F`) print what changed by layer and stage the merge for review. Credits are the other distinctive piece: every balance change writes a ledger entry with an idempotency key in the same D1 batch as the grant and balance updates, so a duplicated provider callback rolls back as a whole. Purchased credits never expire, while the sign-up bonus defaults to an expiry set in runtime settings. Generation runs through fal.ai with a webhook back into the Worker, and jobs are queued with a dead-letter queue and a five-minute health check that emails admins when failure rates cross a threshold.\n\nThe trade-off is that all of this is Cloudflare-shaped. Workers, D1, R2, KV and Queues are hard dependencies, and email leaves through Cloudflare Email Service, which is in public beta. The README is candid that videos carry no burned-in watermark and no C2PA manifest yet, and that comments, ROADMAP and docs are currently in Chinese. Payment flexibility is real but comes with compliance work: Waffo Pancake and Dodo Payments act as merchants of record, whereas Stripe makes you the merchant handling sales tax yourself.\n\n## Who should try it\n\nA good fit is a small operator who wants to test several narrow AI video sites and is willing to keep a template-and-fork workflow with `git merge` rather than squash or rebase. The bundled skills are a convenience, not a requirement: the README documents doing the same sync by hand with the sync-plan script, `git merge` and the test commands, so a Claude Code user is not mandatory. A poor fit is anyone who needs a proven production deployment, non-Cloudflare infrastructure, or an out-of-the-box consumer app without configuration. Sites requiring content provenance metadata should note that C2PA is listed as not yet implemented.\n\n## Requirements and limitations\n\nThe setup path is long before a site is live: Cloudflare resources per site (D1, R2, KV, two queues), remote migrations, seed media uploaded to R2, OAuth and payment webhook URLs registered in each provider's console, and npm 11.19 or newer because older versions rewrite `package-lock.json` in a form CI rejects. Ongoing upkeep is the dual-repo model: every template fix has to be merged into each site, and the sync base only stays correct if you merge rather than squash. The README's own status line is the biggest boundary: local tests pass, but no production deployment has been verified end to end against real services, and [ROADMAP.md](https:\u002F\u002Fgithub.com\u002Fqianshuixia\u002Fshrimpreel\u002Fblob\u002Fmain\u002FROADMAP.md) lists what remains unchecked. For real payment testing without a custom domain, the [staging configuration](https:\u002F\u002Fgithub.com\u002Fqianshuixia\u002Fshrimpreel\u002Fblob\u002Fmain\u002Fwrangler.staging.jsonc) deploys to a `workers.dev` address.\n\n## HotRepo's take\n\nHotRepo first recorded the project at 4 days old, with 260 total stars and #15 on the NEW-REPOSITORY board (typescript) on 2026-10-25; that is a board rank, not a daily growth figure. With only two recorded dates and no comparable daily-board history, persistence cannot be judged. Before investing time, check ROADMAP.md for whether the production deployment, fal.ai callbacks and payment provider flows have been verified against real services since the README was written.",{"slug":19,"name":20},"media","Media & Design",[22,23,24,25,26,27,28,29,30,31,32,33],"ai-video","cloudflare-d1","cloudflare-r2","cloudflare-workers","fal-ai","hono","image-to-video","react","saas-boilerplate","saas-template","tanstack-start","typescript","MIT",null,"2026-10-25T02:51:10Z",[],1792906479]