A walkthrough of the lifecycle behind a two-photo trend video generator: validation, quotes, credit holds, async rendering and data expiry.
Consumer AI video looks like a single button: upload photos, get a clip. Behind that button sits a long-running, paid, failure-prone job, and most of the product work goes into making that job predictable for someone who just wants a funny video of their friends.
This post follows one job through AIHotelLobby.win, a single-purpose tool that recasts the Hotel Lobby trend video with two uploaded portraits. It makes a good example because its public guides, help page, terms and privacy policy spell out every stage, from upload checks to how long each file lives. Everything below is based on those pages; the snippets are simplified sketches of the behavior they describe.
Stage 1: Reject bad input before anything expensive happens
A GPU minute costs far more than a file check, so the cheapest quality control is at the upload box. Each photo has to be a JPG, PNG or WebP, at least 512 × 512 pixels and no larger than 10 MB, showing one clearly visible adult.
const ACCEPTED = ['image/jpeg', 'image/png', 'image/webp'];
const MAX_BYTES = 10 * 1024 * 1024;
function checkPhoto(type: string, bytes: number, w: number, h: number): string | null {
if (!ACCEPTED.includes(type)) return 'Use a JPG, PNG or WebP image';
if (bytes > MAX_BYTES) return 'Keep the file under 10 MB';
if (w < 512 || h < 512) return 'Use an image at least 512 × 512 pixels';
return null;
}
Two details worth noting. Metadata is stripped when the images are prepared, which removes location data people forget their phones attach. And the docs are explicit that these checks only cover the file: they do not verify identity, age or consent. Being honest about what validation can't do is part of the design.
Stage 2: Keep the draft alive through the login wall
Users can pick both photos, assign left and right, and choose length and sound before creating an account. The draft is kept on the device while they sign in, so the login wall doesn't throw away their work. Signing out clears it.
This is a conversion detail as much as a technical one. The moment someone is asked to sign in is the moment they are most likely to leave, and making them redo the upload afterwards doubles that risk.
Stage 3: Quote first, then hold the credits
After sign-in, the photos upload privately and the server returns a quote: length, format and credit cost. Prices are fixed per length (5 seconds is 30 credits, 10 is 50 and 15 is 70), and the quote is pinned to the task.
type Quote = {
durationSeconds: 5 | 10 | 15;
aspect: '16:9';
audio: 'original' | 'silent';
credits: 30 | 50 | 70;
configRevision: string; // the model, template and price recorded for this task
};
The terms make the pinning explicit: prices and models can change for new requests, but an existing task keeps the provider, settings and price recorded in its quote. Confirming the quote reserves the credits. They are captured only after a valid video has been stored, and released if the task definitively fails. Buying credits is a separate flow and never starts a job by itself.
Stage 4: Hand off to the model, then let the user leave
The configured model is Kling 3.0 Omni, accessed through KIE as the API provider. (A second model, Seedance 2.0 Mini, is integrated but not enabled for customers.) The provider receives the two photos, the reference video and the instructions for that task.
From here everything is asynchronous. The published examples list render times from about three to seven and a half minutes, which is far too long to hold a browser tab hostage. The user can close the page; the task keeps running and shows up in My videos on any device signed in to the same account.
The hard case is a timeout during submission: the provider may or may not have accepted the job. Releasing the credits risks giving away a video that will finish anyway; capturing them risks charging for nothing. The answer here is a holding state:
type Job =
| { state: 'reserved' }
| { state: 'running' }
| { state: 'needs_review' } // submission outcome unknown; credits stay held
| { state: 'completed'; videoKey: string } // credits captured
| { state: 'failed' }; // confirmed failure; credits released
The page on credits and task recovery tells users what this means for them: losing the connection does not stop generation, an uncertain task keeps its credits reserved while it is checked, and they should follow that same task rather than start a duplicate. Credit returns and cash refunds are also kept separate, which saves a lot of support confusion.
Stage 5: Deliver briefly, then delete
Personal photos are a liability the moment you no longer need them, and the retention schedule reflects that:
| Data | How long it stays |
|---|---|
| Validated photos never submitted for a task | 24 hours |
| Photos needed by an active or uncertain task | Up to 48 hours |
| Task inputs after the task reaches a final state | Scheduled to expire within 24 hours |
| Finished videos | 7 days |
| A download link | 5 minutes |
Downloads use short-lived signed links. Deleting a file stops new links from being issued, though a link already handed out can work until it expires, and the privacy policy says so plainly. It also notes that provider copies and backups follow their own schedules, which is the kind of caveat most products leave out.
What's worth copying
- Validate cheaply, and say what validation can't check.
- Let the draft survive authentication.
- Pin the quote to the task, so a price or model change never rewrites a job already in flight.
- Model the unknown state explicitly instead of guessing between refund and charge.
- Publish retention times as numbers, not "as long as necessary".
None of this is specific to trend videos. Any product that runs a slow, paid job on someone's personal media faces the same five stages, and users notice when one of them is handled carelessly.
AIHotelLobby.win is an independent service. It is not an official Kling, Seedance or KIE product and is not affiliated with the artists behind "Hotel Lobby". Details come from its public pages as of October 18, 2026.
Top comments (0)