Burning Bridges AI: Shipping a Locked Party-Scene Effect (Silver Cup “Where She At?”)

Posted on Oct 31 • Originally published at burningbridgesvideoai.com

How I shipped a 1–2 photo → vertical AI party-scan video product on Cloudflare Workers, with guest checkout and a video API aggregator instead of wiring every model vendor myself.

Some TikTok formats are scenes, not “styles.” The Burning Bridges party clip is one of those: crystal chandelier light, a silver cup in frame, a hand-over-eyes “where she at?” scan through the crowd. People wanted that beat with their own face — not a blank prompt box and a CapCut timeline.

I built burningbridgesvideoai.com for that job. Upload 1–2 adult photos, pay once, get a 720p MP4 with sound. No account required for a single pack. Product framing: independent fan tool — not affiliated with any label or artist. This post is the builder walkthrough: effect-niche product shape, stack, credit/payment loop, and how video generation goes through TryAllAPI into Seedance. Prices and model ids change; treat live site / console as source of truth.

Free-form video models are flexible and messy. For a viral-format product, mess kills conversion. Users bounce when they have to invent a storyboard, guess camera language, and still get the wrong roles.

That trade-off is intentional. Repeatable results beat infinite creative control when the job is “ship the recognizable format tonight.” One clear lead photo is enough. The UI refuses celebrity / MV stills on purpose — that copy is product policy, not decoration.

Live pricing on the create path (verified on the site while writing this): 720p from $8.88 (≈ 500 credits for one 720p), with multi-packs such as $16.99 and larger. Guest Stripe checkout is the default path for “I only want one video.”

I did not start from a blank framework. The site sits on a TanStack Start template I maintain ( shipany-tanstack ), deployed to Cloudflare Workers, with D1 for users / orders / credit ledger / generation tasks, and Stripe Checkout for packs.

1–2 photos → locked party template prompt → check credits (else Stripe) → Worker creates Seedance task via TryAllAPI → poll until MP4 URL → store / show → on failure: refund credits Enter fullscreen mode Exit fullscreen mode

Demo clips on the homepage are self-generated samples hosted with the site, so visitors can judge the format before paying. Do not scrape other products’ CDN videos for demos — it is both unnecessary and a compliance mess.

Direct vendor onboarding for every video model means accounts, KYC, docs drift, and different async status machines. For a small indie product I wanted one API key in Workers Secrets, USD balance billed by usage, and a path to Seedance (and fallbacks) without rewriting the client each time the console UI changes.

That is what TryAllAPI is for on this project: aggregate models behind one base URL, keep the site focused on UX + credits + Stripe.

Operational checklist after register / top-up:

Conceptually the call shape looks like this (field names follow the aggregator’s v3 contents API; always re-check current docs):

POST /api/v3/contents/generations/tasks Authorization: Bearer <TRYALLAPI_API_KEY> Content-Type: application/json Accept-Encoding: identity GET /api/v3/contents/generations/tasks/{id} Enter fullscreen mode Exit fullscreen mode I send Accept-Encoding: identity from the Worker because some gateways behave badly with transparent decompression. Model ids used in production look like Seedance 2.x family strings — treat console ids as source of truth, not this paragraph.

A few details that bit me across this family of sites:

Rough mental model for upstream cost (illustrative only — use your own usage fields and invoices):

tokens ≈ duration_sec × width × height × fps / 1024 cost ≈ tokens × price_per_million_tokens Enter fullscreen mode Exit fullscreen mode Price the site after you measure a few real 720p runs with retry margin, Stripe fees, and failed-job refunds — not from a spreadsheet fantasy of 0% failure.

Demo UIs are easy. The line between toy and product is:

Two books of account stay separate: USD balance at TryAllAPI (your cost) vs site credits (what you sold). Mixing them in one mental ledger is how you underprice or invent “mysterious” losses.

When several products share one Stripe account, isolate webhooks by endpoint or by metadata ( site / product ). Callbacks pointed at the wrong apex domain are a classic multi-site footgun.

Secrets stay in Workers: TRYALLAPI_API_KEY, STRIPE_SECRET_KEY, webhook secret, auth secrets. The browser only ever sees publishable Stripe keys if needed.

pnpm install # wire D1 database_id, production env, custom domain in wrangler pnpm cf:deploy Enter fullscreen mode Exit fullscreen mode Before calling a deploy “done”:

For this product, production origin is https://burningbridgesvideoai.com (alternate hostname exists for marketing, but keep auth/webhook allowlists aligned with what Checkout actually returns).

Face-based generation is not “just another SaaS CRUD app”:

Those constraints belong in the product, not in a footnote you add after the first dispute email.

If you want the consumer path: open burningbridgesvideoai.com, watch the sample, upload adult photos you have rights to (lead required; friend optional), pick your pack, pay once.

If you want the builder path: register at TryAllAPI, top up a small USD balance, create a token with the right video group, prove create+poll in a Worker, then wire credits and Stripe. Keep keys out of git. Make failure boring and refundable.

That is the whole product thesis in one sentence: template the party scene, sell the credits, outsource the GPU drama.