DEV Community: visiohex

Why I don't automatically retry timed-out AI video requests

visiohex — Sun, 01 Nov 2026 15:11:15 +0000

A request times out. The obvious next step is to try again.

For a video generation request, that can be an expensive guess. The provider may already be rendering the first video. You just didn't receive its task ID.

I'm working on AI Effect Studio, where people choose an effect, upload photos, and get a short video. The generation backend has to deal with this gap between sending a paid request and knowing what happened to it.

Here's how the current implementation handles it, including the part that still needs manual review.

The timeout doesn't tell you enough

Imagine this sequence:

Our server sends a generation request.
The provider accepts it and starts work.
The connection drops before our server receives the response.

From our side, the request failed. From the provider's side, there's a video being generated.

Sending the same payload again doesn't necessarily resume that work. Unless the provider supports a documented idempotency mechanism, it may create another paid task.

Exponential backoff changes when that second request happens. It doesn't make the second request safe.

Record the attempt before sending it

Each local job stores a submission timestamp separately from its provider task ID. Before calling the generation API, the worker records that it's about to submit.

That gives the next worker enough information to distinguish these cases:

What the job has	What the worker does
No submission marker and no provider ID	Claim the job, record the attempt, then submit
A provider ID	Query that existing task
A submission marker but no provider ID	Hold the job for support review
An output URL already recorded	Continue processing or saving that video

The database updates are conditional, and processing uses a short lease so overlapping workers don't casually pick up the same job. The submission marker is checked and written in the database before the external call.

There's an awkward consequence here. If the worker crashes after writing the marker but before sending the request, the job also ends up waiting for review. It might never have reached the provider.

I accept that tradeoff for the expensive generation step. The marker prevents an automatic second submission, but it cannot prove that the first one happened. This is a conservative fallback, and it leaves some real work for support.

A provider-side idempotency key would be a better way to close that gap. A local timestamp can't give us exactly-once execution across two systems.

Retry the stage that failed

A video job keeps going after the model finishes. Depending on the effect, there's a soundtrack step, followed by saving the output to our own storage.

If storage fails, generating another video would be a costly way to retry a file transfer. The job records the source video URL so recovery can continue from the output it already has.

The soundtrack step has a different retry policy. It's much cheaper than generation, so it gets bounded retries. If those are exhausted, the delivery path can fall back to the silent footage. That is a product compromise: the user gets a video, but the soundtrack may be missing. The interface and product description need to make that possibility clear.

Credits need the same care. A confirmed generation failure restores the user's allowance. An ambiguous submission stays reserved while it's investigated, because a timeout alone doesn't tell us whether paid work is still running.

The question I use when reviewing these paths is pretty mundane: if this line runs twice, do we check the same work, or buy more work?

Polling an existing task, copying an existing output, and starting a fresh render deserve different answers. Putting all three behind one generic retry helper would hide the distinction I most need to see.

Building the photo upload form for Tiny Desk AI

visiohex — Sun, 01 Nov 2026 14:31:10 +0000

The upload form in Tiny Desk AI has three possible seats: lead singer, sax player, and keyboard player. You choose Solo, Duo, or Trio, then add one photo per person. The output is a short AI-generated desk-concert clip with a fixed sequence.

I'm working on this project. This post is about the photo form, because even with only three inputs, there are a few ways to lose someone's choices or assign a photo to the wrong seat.

Give each photo a role

The form stores photos by role:

const CAST_ROLES = ['lead', 'sax', 'keys'] as const;
type CastRole = (typeof CAST_ROLES)[number];
type Photos = Partial<Record<CastRole, File>>;

The selected cast size controls which roles are visible:

const seats = CAST_ROLES.slice(0, cast);

That leaves one ordering to use for rendering the inputs and building the upload list. The singer stays the singer when someone switches from Trio to Solo and back.

Switching the cast size doesn't delete the hidden photos. Removing a photo is a separate action. Someone can compare the options without having to pick the same files again.

There is a limit to this design: each cast is a prefix of the same list. It works for this product because Duo always means lead plus sax. If we added a lead-and-keyboard option, a count alone would no longer describe the selection.

A thumbnail isn't the upload

Each selected file gets an object URL for its preview. The component revokes that URL when the file changes or the component unmounts.

The form also checks that the browser can decode the image, then checks its dimensions and aspect ratio. A file picker accepting JPEG, PNG, and WebP only helps with selection; it doesn't prove that the file is usable. These browser checks give earlier feedback. Server-side validation still has to protect the upload endpoint.

After a successful upload, the form remembers both the File object and the returned upload ID for that role. On another submission attempt, an unchanged file can reuse its ID. Choosing a replacement clears the cached upload for that seat.

That distinction matters when one upload succeeds and a later one fails. There is no reason to send the first photo again while the page still has its successful upload recorded.

Restoring a draft can race with the user

Selected files are saved in IndexedDB. Session storage holds a reference for each role, and the saved records have a 24-hour validity window. This is local recovery in the current browser session, with no cross-device promise.

Loading those files is asynchronous. A person can select a new photo before restoration finishes. If the old draft then overwrites the new selection, the form has undone their work.

The component keeps a choice counter. Restoration only applies while that counter is still zero. Once someone starts choosing photos, their current choices take precedence.

The storage helper also waits for the IndexedDB transaction to complete before resolving a save. A successful put request alone isn't enough: the transaction can still abort.

What the form can't promise

A clear preview and a correct role assignment don't guarantee a good generated video. Faces can drift, especially through motion. The homepage shows the input photos alongside sample results and explains which parts of the clip are fixed, so people can judge the format before paying.

The frontend has a narrower job: keep the selected photos in the right seats, explain invalid inputs, and preserve work where it can. For this form, those details deserve as much attention as the generate button.

Angry Dance Filter AI: Engineering a Fixed-Format Video Workflow

visiohex — Tue, 27 Oct 2026 15:56:00 +0000

A one-photo video tool has a small interface, but a surprisingly demanding backend. The user uploads a picture, pays, and expects a finished file. Behind that interaction are several separate questions: what exactly was promised, was a generation request accepted, and is the returned video safe to deliver?

This is a technical walkthrough of decisions in my project, Angry Dance Filter AI. It turns a photo into a specific kitchen dance routine. The useful engineering details are the boundaries around the generation request.

Start with one defined output

The product accepts one photo and targets a 14-second, vertical 9:16, 720p video with audio. The routine and kitchen come from a reference clip; the photo supplies the person's appearance. Users do not write a prompt or choose a different background.

That narrow scope makes the output contract concrete. In the TypeScript implementation, it is represented as:

export const PUBLIC_OUTPUT = {
  durationSeconds: 14,
  aspectRatio: '9:16',
  resolution: '720p',
  audio: true,
} as const;

Runtime validation checks deployment settings against that contract. If they disagree, new generation is unavailable rather than silently selling a different format.

This matters beyond the model call. A resolution change also affects checkout text, emails, translated copy, and documentation. A shared contract reduces drift, although prose that repeats those values still needs review.

Let the reference clip carry the motion

The generation request uses NanoAPI's Genjutsu model in motion-control mode. The server builds the request from a signed photo URL, a reference video URL, a server-owned prompt, an explicit resolution, and a webhook URL.

In this integration, the reference clip supplies the length, framing, motion, and audio. There is no separate duration or audio parameter in the task body, and no extra audio-merging stage in this path.

The tradeoff is limited creative control. The same scene and routine are part of the product contract. It also does not make identity preservation deterministic: faces, clothing details, and hands can still drift. The interface needs to explain those limits before someone uploads a photo.

A timeout is an unknown outcome

The most consequential failure case happens when the provider might have accepted a paid request, but the response never reaches the application.

Automatically repeating that POST can create a second task. Returning the user's credit immediately can also be wrong if the original task is still running.

The job processor therefore records a submission marker before sending the request and persists the exact provider request body. Once a task ID is available, subsequent processing reads that task instead of creating another one.

If submission was attempted but no task ID was recovered, the job is held for support review. The allowance remains reserved. A definitely rejected request follows a different path and can restore the allowance.

This is a deliberate tradeoff: an ambiguous job may need manual reconciliation. The marker does not create exactly-once delivery across two systems. In particular, a crash between recording the marker and sending the request can leave a job needing review even though nothing reached the provider.

Treat webhooks as a reason to check

The callback handler verifies a signature over the raw request body before parsing it. It also bounds the body size and checks the timestamp.

After validation, it uses the task ID to locate the local job and trigger processing. It does not trust a callback's success flag or output URL as the final result. The processor fetches the task through the provider API and checks its ID and model before advancing the job.

Signature verification and an authoritative task read solve different problems. The first authenticates the notification; the second determines the current task state. Neither replaces guarded updates in the local job processor.

Make failure behavior explicit in tests

The repository includes regression cases for ambiguous submissions, repeated processing, request snapshots, invalid webhook signatures, and mismatched task IDs or models.

One particularly useful assertion is that a simulated network timeout followed by another processing pass still produces only one provider submission. Another supplies a signed callback claiming success while the task API reports failure; the task API state wins.

For this kind of application, the small upload form is only the entrance. The design work is in preserving the output contract and distinguishing confirmed failure from uncertainty, without quietly creating another paid operation.

Day 1 of Owning a Roadster V2: A One-Photo Video Generator

visiohex — Sun, 18 Oct 2026 03:42:53 +0000

I built Day 1 of Owning a Roadster, a small photo-to-video site for one specific clip: a driver in a white Roadster gets stuck in rainy traffic, hits a button, and takes off. There is a loop in the air and a cup of coffee that does not survive the ride.

You upload a photo of yourself or your pet. The site uses that photo for the driver and keeps the Roadster V2 sequence fixed.

Keeping the input small

The main choice on the site is the photo. You do not have to write a prompt, select a model, or piece together scenes. The homepage shows the reference and a cat example before you reach checkout.

That fixed format comes with a limit: you can change the driver, but you cannot pick another car, outfit, or storyline. I would rather make that clear before someone pays.

From upload to download

The flow is photo, delivery email, video pack, payment, then a private order page. Generation starts after payment is confirmed. You can leave the browser and come back through the link in your email to check progress or download the result.

There is no account to create. A single video costs $9.99 USD, with three-video and ten-video packs available as one-time purchases. The output is about 13 seconds, vertical 9:16 at 720p, with sound and no watermark.

If generation is confirmed to have failed, the used credit returns to the order for another attempt. Finished videos stay available for 30 days, so you should download a copy.

The part you should check in a sample

A generated clip will not reproduce the reference frame for frame. Faces, fur, clothing, and movement can change. A clear, well-lit portrait gives the model more to work with, but you should still watch the whole result with sound before sharing it. Only upload photos you own or have permission to use.

The site is live: day1ofowningaroadster.com.

I would be interested in feedback on the upload and order flow. Is it clear what you will get before you reach payment?

Ozil Goal AI: A Photo-to-Video Football Side Project

visiohex — Sat, 17 Oct 2026 11:57:50 +0000

I built Ozil Goal AI, a small AI football video generator that turns one portrait into a goal video inspired by Özil’s finish against Ludogorets.

The idea is fairly simple: you supply the person, and the site supplies the football scene. There’s no prompt box to learn and no account to create.

A deliberately short input flow

You upload a clear photo of one person, then choose one of four football kits or keep the clothes in the photo. After entering a delivery email and choosing a one-time pack, payment starts the first video.

The output is a 15-second, 720p, vertical 9:16 MP4. A private order link arrives by email, so you can leave the page while the video processes and return later.

For a tool built around a single scene, I wanted the choices to stay concrete. A kit selector says more about the possible result than asking someone to describe a football outfit in a prompt.

The website around the model

The web app uses TanStack Start, React, and TypeScript on Cloudflare Workers, with D1 and R2. Video generation comes from an existing model API. My work is the product around it: the input flow, kit choices, payment, order status, and delivery.

The homepage has playable examples because the output needs to be judged in motion. A convincing face in one frame doesn’t tell you whether it will hold up through a turn. The feet and ball can drift too.

This is photo-to-video generation, so it creates new frames rather than replacing a face in the original footage. Likeness, clothing, and movement can vary. I try to make that visible before someone pays.

Try the samples

The samples are free to watch. Personal video generation starts at $12.99 USD as a one-time purchase, with no subscription. Applicable taxes may be added.

You can find the site at https://ozil-goal.org/. It’s an independent entertainment project with no affiliation to Özil or any club.

If you build image-to-video tools, I’d be interested in how you show the limits of the output before checkout. For this project, playable examples felt like the most useful place to start.

Crazy Frog AI Video Generator: Handling Timeouts Without Creating Duplicate Jobs

visiohex — Sat, 17 Oct 2026 08:58:11 +0000

A video generation request can time out after the provider has accepted it. If you treat that timeout as permission to submit again, you can end up paying for two generations while your user waits for one.

That's a failure case I wanted to account for while building Crazy Frog AI Video Generator. The interface takes two photos, assigns a rider and a chaser, and creates an invisible motorcycle chase. Behind it, I use TypeScript on Cloudflare Workers, D1 for job state, and R2 for the finished media.

The part I want to share is how I separate a browser retry, a provider status check, and a new paid task. They need different rules.

Keep the browser request attached to one job

The client supplies a request ID. On the server, I validate the inputs and use that ID as the job ID. I store the validated inputs and the provider request body before contacting the video service.

When the browser repeats a request with the same ID, the server checks the owner and stored inputs. Matching requests return the existing job. Reusing the ID with different inputs produces an error.

This handles repeated HTTP requests on our side. The remote submission still needs its own recovery path: our database and the provider don't share a transaction.

Record submission intent before the network call

Before creating a provider task, the worker writes a submission timestamp to the job row. It stores the provider's task ID when the response arrives.

A later worker can make a decision from those two fields:

Submission marker	Provider task ID	Next action
Absent	Absent	Claim the job and attempt the first submission
Present	Present	Check that existing task
Present	Absent	Pause for reconciliation; don't submit another task

The third row includes an uncomfortable case. A worker might save the marker and stop before sending the request. We then pause a job that the provider never received.

I accept that tradeoff in the current implementation. Without a verified way to deduplicate a provider submission, I can't distinguish that case from a provider accepting the request and losing the response. For an ambiguous submission, the app keeps the video allowance reserved and shows a support-review message. A confirmed rejection follows a separate failure path that restores the allowance.

If I add a provider-supported idempotency key later, I'll need to verify its scope and retention window before changing this behavior.

A lease needs protection against late writes

A worker claims a pending job with a two-minute lease. Another worker can take over after that lease expires.

That creates a second problem: the first worker may still be waiting on a provider or storage operation. When it resumes, it must not overwrite the newer worker's state.

I use an incrementing claim token, stored in the attempts column. Claiming a job increments it. State updates check both that token and the lease. This is the guard used by the update helper, with the SET clause omitted:

WHERE id = ?
  AND attempts = ?
  AND lease_until > ?
  AND status IN ('queued', 'processing', 'composing', 'saving')
RETURNING *

I also include the claim token in output object names. If an older worker finishes an upload late, it writes to a separate object rather than replacing the newer output.

These checks protect local state and files. They don't make an external API call exactly-once, so the submission marker still matters.

Recover each stage on its own

The workflow has separate stages:

queued -> processing -> composing -> saving -> succeeded

The video provider generates silent output. A separate composition task adds the selected scene's audio. The app then downloads and validates the result and stores it in R2 before marking the job as succeeded.

If storage fails after composition, recovery can continue from the existing task and result. Starting video generation over would repeat the most expensive part of the workflow.

Audio composition also has a submission marker and task ID. Moving a paid operation into a later stage doesn't remove the lost-response problem.

For callbacks, I verify the request, identify the stored job, and wake processing. The worker asks the provider for current task state rather than accepting the callback's output as final. A reconciliation pass checks pending jobs too, with backoff and jitter between attempts.

What I'd check before changing the retry policy

The cases I care about include a repeated client request, a timeout after provider acceptance, a worker resuming after its lease expires, and an R2 write failing after composition. Each case needs a different recovery action.

I haven't removed the manual work from ambiguous submissions. For now, I prefer that visible operational limit to creating a second paid task because the first response went missing.

You can see the product this supports at crazy-frog-ai.org. If you've handled ambiguous submissions with a provider that offers limited task lookup, I'd be interested in how you reconcile them.

Building Unforgettable Car AI: one portrait, one car reveal

visiohex — Thu, 15 Oct 2026 07:59:28 +0000

I built Unforgettable Car AI, a small web app that turns a portrait into a car reveal video.

You may have seen the format: someone holds up a 2 and a 4 card, covers the camera with a hand, and reveals a car when the lens clears. The app follows that sequence, with your photo as the starting point.

The idea is easy to explain in a sentence. Making the creation flow equally easy to understand is the part I care about.

A small set of choices

The homepage has examples you can watch before signing in. There are short previews and full 15-second clips, so you can see the movement and the reveal before deciding whether to make one.

To create a video, sign in with Google, upload a clear portrait, and choose a car and a setting. A regular selfie works; you do not need to be holding cards or standing beside a vehicle.

There are three cars: a black SUV, a green supercar, and a red coupe. You can pair any of them with an underground garage, a rooftop parking area, or a city street. That gives you nine combinations without a long configuration form.

There is no prompt to write. The reference sequence guides the card gesture, the hand over the lens, and the reveal. When the job finishes, the result appears in My videos, where you can watch and download it.

What sits around the video model

The web app uses TanStack Start, React, and Cloudflare Workers. It connects to an existing video generation service.

The application work is in the flow around that service: collecting a portrait, keeping the car and scene choices separate, tracking the generation job, and making the finished file available to the person who requested it.

For this kind of app, those steps are a big part of the experience. Uploading a photo is quick. Generation takes longer. The interface needs to make it clear that the request is still being processed and where the result will appear.

The examples matter for a similar reason. A screenshot cannot show whether a hand movement or a transition feels right. Watching a full sample gives someone a more useful basis for deciding whether to try it.

The output and its limits

The result is a 15-second, 16:9 MP4, with a 720p output setting. It is silent: the Unforgettable song is not bundled with the download. Adding music or making a vertical edit is a separate step.

The model creates new footage, so facial details, hands, clothing, and timing can vary. I would watch the entire clip before sharing it, especially the moment when the hand crosses the face.

Viewing the public examples is free. Personal video generation is paid through one-time packs, with a single-video pack currently at $12.99 USD before applicable taxes. There is no subscription, and a generation confirmed as failed returns its credit.

Uploads and generated videos are private to your account. Photos are retained for up to seven days and videos for 30 days, so you should download anything you want to keep.

You can see the samples at unforgettablecar.org.

If you take a look, I would be interested in feedback on the creation flow. Do the examples make the output clear enough, and is there anything you would want to know before uploading a photo?

I built a two-photo video generator for the Alors on danse keyboard meme

visiohex — Tue, 13 Oct 2026 16:36:57 +0000

The first photo becomes the keyboard player. The second becomes the partner reacting alongside them. You can use two people, two pets, or one of each.

That is the starting point for Alors on Danse AI, a small website I built around the Stromae and Jamel Debbouze white-studio keyboard sketch. It makes one specific scene: a 16-second video with your chosen duo and the original audio.

I wanted the setup to be understandable before anyone uploaded a photo. The page has two slots, each labeled with a role. You do not need to write a prompt, find a template file, or install an editor.

One scene, two choices

The left/right distinction is a small UI detail that matters. “Upload two images” leaves a question unanswered: which subject does what?

The first slot is the keyboard player on the left. The second is the expressive partner on the right. Both roles are replaced. The studio, movement reference, duration, and soundtrack stay fixed.

That also sets a clear boundary for the product. It will not make a different dance, change the music, or turn into a general video editor. The useful choice here is who you put into the scene.

A dog on the keyboard

One public example uses a synthetic golden retriever photo for the keyboard player and a synthetic human portrait for the partner.

This is a still from the 16-second test example. That sample was generated at 480p; the standard paid output is 720p.

The examples page shows the two input photos beside the generated clip. It also includes the scene reference, labeled separately. I think seeing the inputs and result together is more useful than a polished clip with no explanation of where it came from.

Pets are the fun part, but also a good reminder of the limits. The scene asks them to perform upright, human-like gestures. Fur, paws, faces, and movement can change during generation. A recognizable subject in one frame does not guarantee an equally convincing result throughout the clip.

What happens behind the button

The app uses React and TanStack Start on Cloudflare Workers. D1 stores accounts, credits, and job state; R2 stores uploaded photos and finished videos.

The generation pipeline has two stages. Seedance 2.5 through KIE generates the video with audio generation turned off. A separate FAL step merges the fixed soundtrack into the result.

Separating those steps means the job is not finished just because the video model returned a file. The audio merge and storage still need to complete before there is an MP4 to download.

There is also the less exciting part of a paid generation app: repeated clicks, delayed callbacks, and uncertain provider responses. The backend tracks each request, checks provider results, and has a recovery job for tasks that need another look. A confirmed failed generation restores one video credit. An uncertain result stays under review rather than immediately triggering another paid generation.

Using it, and knowing what to expect

The user flow is short: sign in with Google, choose a video pack, upload one photo for each role, and generate. Progress and completed downloads appear in My videos.

The standard output is a 16-second, 720p, 16:9 landscape MP4. Packs are one-time purchases, starting at $12.99 for one video, without a subscription. There is no free generation trial; the public examples are available to watch before buying.

Clear, separate photos work best. Group shots and obscured faces make the role assignment harder. Use photos you have permission to upload.

Photos are retained for up to seven days and finished videos for 30 days, so download the MP4 if you want to keep it. The restored credit after a failed task is a generation credit, not a cash refund.

You can see the current version at alorsondanseaivideo.net. I would be interested in feedback on the two-role setup: is it obvious which photo goes where, and do the examples give you enough information to judge the result before paying?

Why I Kept My AI Video Tool to One Scene

visiohex — Sun, 11 Oct 2026 12:27:00 +0000

I built Bulin 47 AI, a small browser tool that takes one portrait and makes a version of the Bulin 47 freestyle clip.

The result is a 10-second vertical video. The portrait guides the main rapper’s appearance, while a fixed reference video guides the performance and surrounding scene. The reference soundtrack is included.

The main product decision was to keep it to that one scene.

Deciding what the user actually needs to choose

A general video generator needs room for prompts, model selection, reference footage, duration and output settings. For this particular clip, most of those choices can be made ahead of time.

I’ve already prepared the reference clip, prompt and audio. The person using the site mainly needs to decide who should appear in the video.

That makes the upload form smaller, but it also sets a clear boundary. The tool doesn’t offer custom choreography or a library of different performances. If you want a different scene, this isn’t the right tool for it.

The photo and video reference have separate jobs. A clear portrait helps with appearance; the reference supplies the movement. There’s no need to record yourself performing or upload a full-body shot.

A small form still needs to explain the result

The flow is straightforward: watch the reference, sign in with Google, upload a portrait and submit a generation. You can follow its progress in My videos, then download the finished MP4.

The output is fixed at 720p, 10 seconds and a 9:16 aspect ratio. Those details belong near the upload form, because they affect whether the result will work for someone’s intended use.

There are less tidy details to explain too. A face can look convincing in the first frame and change when the person turns. Hands and timing need checking. The model creates new frames, so appearance and motion can vary between generations.

A completed job doesn’t necessarily mean the person will like the result. That matters when explaining credits: confirmed failed generations return the credit, while a completed video with an unsatisfying likeness is a different situation.

Keeping the examples honest

The homepage includes the reference and trend examples so people can see the scene before paying. Those gallery clips come from outside creators, are credited on the site and weren’t generated by this service.

That distinction needs to be visible. A reference clip shows what the tool is aiming for; it doesn’t prove what every generation will look like.

Making a video requires a paid credit. There are no free generations at the moment. Credits are sold in one-time packs, with no subscription or automatic renewal. The current options are on the pricing page.

A few limits worth stating upfront

Photos are kept for up to seven days and finished videos for 30 days. Download any result you want to keep. Get permission before using someone else’s portrait, and label shared clips as AI-generated.

Keeping the scope small gives me a specific workflow to improve: one portrait, one scene, one downloadable result. I’m interested in whether that constraint makes the process easier to understand, and where the form still leaves people guessing.

You can see it at bulin47.online. If you take a look, I’d appreciate feedback on the upload flow and how clearly it explains what you’ll get.

AI Raindance: make a 15-second music video from one or two portraits

visiohex — Sun, 11 Oct 2026 04:21:33 +0000

I built AI Raindance, a web app that puts people from your photos into a short video inspired by Dave and Tems' Raindance music video.

You choose who appears in the scene. The app supplies the reference, the waterfront setting and the original audio. There's no prompt to write: upload one or two portraits, choose the roles, and generate a 15-second MP4.

Here's how it works, and what to check before spending a video credit.

Start with the cast

There are two modes:

Mode	Photos	Who appears
Solo	One portrait	The person in your photo becomes the singer; the companion is removed.
Duo	Two separate portraits	Photo 1 is the companion, and photo 2 is the singer.

For Duo, you don't need a picture of both people together. Use a separate portrait for each person. If you've put the singer in the first slot, use Swap roles before generating.

Both modes cost one video credit. Adding a second person doesn't cost extra.

Choose a photo where the face is easy to see

A front-facing portrait or a slight angle is a good starting point. Keep the face large enough to see clearly, with even lighting and no sunglasses or heavy filters. Group shots and faces far from the camera are harder to work with.

The app accepts JPEG, PNG and WebP files, up to 10 MB per photo. Use your own photos, or photos you have permission to use with the subject's consent.

Sign in before selecting them. The uploaded photos aren't saved as an unfinished draft, so leaving the page before submitting can lose your selection.

Make and download the video

Sign in with Google. If your balance is empty, buy a one-time video pack.
Choose Solo or Duo, add your portraits and check the role labels.
Click Generate to submit the task and use one credit.
Open My videos to follow its progress, play the result and download the MP4.

Once you've submitted the task, you can close the page. Return with the same Google account to find it again. You don't need to keep a browser tab open throughout generation.

The finished video is 15 seconds, 768P, in a 4:3 frame, with the original reference audio included. Your portrait changes the person on screen; it doesn't turn your voice into the song.

Watch the whole clip before sharing it. Facial details, expressions and singing timing can vary between AI results.

Look at the sample before buying

The examples page separates the original reference footage from a generated Solo sample.

That sample is a short 4.5-second clip made from a fictional AI portrait, with its model-generated soundtrack. It isn't a full preview of a purchased video. Purchased videos use the fixed 15-second template and original Raindance audio.

The template is deliberately specific: you can choose the portraits and roles, but you can't change the song, scene or duration.

Cost and file storage

Generation is paid. The current packs are $9.99 for one video, $24.99 for three, or $69.99 for ten. There is no subscription, and purchased credits don't expire. If a task is confirmed as failed, its credit is returned automatically.

Photos are kept for seven days and finished videos for thirty days. Download the MP4 while it's available. Uploads and finished videos stay in your account; they aren't automatically added to the public examples page.

AI Raindance is an independent project, with no affiliation with Dave or Tems.

You can try the flow at airaindance.online. I'd welcome feedback on the Solo/Duo controls, especially whether the companion and singer roles are clear before you upload.

I built a one-photo Burning Bridges video generator

visiohex — Sun, 11 Oct 2026 03:59:51 +0000

I built Drake Burning Bridges AI, a small web app that takes one portrait and generates a personal version of the Burning Bridges party scene.

You choose the main character with your photo. I’ve configured the video reference and prompt, so you don’t have to write scene instructions. The output is a 20-second, 720p, landscape MP4 with the supplied soundtrack.

For this post, I wanted to share the implementation choices behind that short upload flow.

Keeping the input small

The studio accepts one portrait. The photo provides the appearance reference for the main subject; the video reference guides the party setting, gestures and camera movement.

I kept the scene and output settings fixed. Users can choose who appears in the foreground, but they can’t cast each guest or change the duration. That limits what you can make, and it gives the upload page a clear job: help you choose a usable photo and understand the expected result.

The server checks file size, image type and dimensions. A file extension or a browser-provided MIME type alone isn’t enough to validate an upload.

The stack

I’m using React and TanStack Start for the app, with Better Auth for authentication. The application runs on Cloudflare Workers. I store task and credit records in D1, and uploaded photos and finished videos in R2.

The app calls an external video generation service. Workers handle the application flow rather than running video inference themselves.

Treating generation as a saved job

A video request needs to survive the user leaving the page. I store the job before processing it and track its progress through these states:

queued → processing → composing → saving → succeeded

The composition step adds the supplied soundtrack. I mark a task as successful after saving the finished video, rather than when the generation provider first reports success.

Users can return to My videos to check an existing task. The browser doesn’t have to stay open for the whole operation.

Handling retries and credits

Each generation uses one credit. I use a request ID to connect a submission to its job. If the same user sends the same request again, the application returns the existing job. Reusing that ID with different input is rejected.

In the database, I connect job creation to the credit debit with a trigger. If the debit can’t complete, the job insert rolls back. I also give failed-job credit returns a unique ledger reference, so processing the same failure again doesn’t add another credit.

The less obvious case is a timeout while submitting to the video provider. The provider might have accepted the job even though my application didn’t receive its response. Submitting a fresh request at that point could create a second paid generation.

I record that submission attempt and keep an uncertain outcome for reconciliation. A confirmed failure returns the credit; a missing response needs more investigation. This leaves some cases requiring support review, but avoids treating an unknown result as permission to submit again.

Setting expectations for the video

AI can change facial details or hands as the person moves. A completed job means the user received a video, not that the model preserved their appearance in every frame.

I’ve included examples so visitors can inspect the intended scene. Those are supplied 480p samples, not evidence of a paid generation through the app. The configured output is 720p.

The site is an independent project with no affiliation with Drake. Users should upload photos they have permission to use, with the subject’s consent.

You can see the project at drakeburningbridgesai.video. I’d welcome feedback on the upload flow, or how you handle uncertain provider responses in apps that charge per task.

I built AI Zombie: two photos, a 15-second zombie love story

visiohex — Sun, 11 Oct 2026 03:55:02 +0000

I built AI Zombie, a web app that turns two photos into a 15-second zombie love story with sound.

The story starts with a survivor facing someone they care about who has become a zombie. Instead of shooting, the survivor lowers the weapon and opens their arms. The zombie approaches, they embrace, and the scene cuts to a warm memory of them together.

You can use photos of two people, or make your dog or cat the zombie and keep yourself as the human survivor.

How it works

Upload a photo of the person or pet who becomes the zombie.
Upload a photo of the human survivor.
Choose a cabin, city, or chapel setting, and a portrait or landscape format.
Start the generation, then watch and download the finished video from My videos.

The output is a 15-second, 720p MP4 with audio. The homepage includes example videos if you want to see the style before creating one. Generation uses paid video credits.

Giving the model a specific story

I kept the generator focused on one short narrative. You choose the characters and setting; the app supplies the sequence of shots.

In the implementation, I build the video prompt around timed story beats: recognition, the survivor's decision, the approach, the embrace, and the memory. The transition is the part I care about most. I ask the model to keep the characters in the same positions across the cut, so the embrace connects the present to the memory.

The pet version needs different instructions. I ask for a natural four-legged trot and a short jump that fits the animal's size. The prompt also specifies that the model should preserve the pet's markings and species rather than give it human limbs or gestures.

These are instructions to the model, rather than guarantees. Faces, motion, and sound can vary between generations, and the model may miss a detail in the intended sequence.

A few implementation details

I built the app with TanStack Start and React, running on Cloudflare Workers. I use D1 for generation records and R2 for media storage. The video generation itself runs through an external API.

A generation takes longer than a normal page request, so I store it as a job. The UI shows its status while the backend handles submission and completion. Users can return to their video history to find the result.

I also use a request ID to handle repeated submissions. If a user retries the same request, the backend returns the existing job instead of creating another one. That matters when each generation consumes a paid credit.

I'd like your feedback

You can see the examples and try the generator at aizombie.online.

I'm interested in whether the story makes sense when you watch it, and whether the upload flow makes the two character roles clear. If you're building an image-to-video app, I'd also like to hear how you handle continuity between shots.