This autumn I shipped a small web app that turns one or two photos into a 15-second AI video for a TikTok trend. The product side is simple: upload photos, pick an effect, wait, download. The engineering side has one hard constraint. A video takes several minutes to render on the model provider's side, and our app runs on Cloudflare Workers, where a request should finish in seconds.

Here is the design we ended up with, plus the three bugs that kept every production render from working on launch week.

The rule: no request waits for a video

Every request does one small, fast step and returns. The render itself lives in a database row that moves through a short list of states:

reserved -> submitting -> running -> succeeded / failed
                       \-> uncertain -> running / failed

• Quote. The browser asks for a price first. The server works out the cost from the model, length and format, and the user sees it before paying anything.
• Create. On "Generate", the server reserves that amount from the user's balance and writes the task row in the same transaction. Then it submits the job to the provider.
• Poll and reconcile. The browser polls a cheap status endpoint. A scheduled job also checks tasks that have not moved for a while, so a closed tab never leaves a render stuck.
• Settle. When the provider reports success, we copy the file into our own private storage, then charge the reservation. On failure we release it, so the credits go back automatically.

Why there is an uncertain state

The interesting failure is not "the provider said no". It is "we sent the job and the connection died before we got an answer". Did the provider accept it or not? If you mark it failed and refund, you might pay for a render you never deliver. If you retry, you might pay twice.

So the task goes to uncertain, and only the reconcile step can move it on, after asking the provider what it actually has. It is one extra state, and it removed a whole class of "I was charged but got nothing" support emails before they happened.

Money as integers

The ledger stores amounts as integer micro-dollars, and the users see credits. Every function that touches money checks that its input is a safe, non-negative integer and throws if not. Floating point never gets near a balance.

Copy the result before you show it

Provider download links expire. If you store their URL, your users' videos quietly vanish a few days later. We copy every finished file into a private bucket and serve it through short-lived signed links. That way the video stays in the user's library until they delete it.

Three launch-week bugs worth stealing

1. A safety cap that blocked everything. I had added a per-task cost ceiling as a guard against runaway spend. Then the default model got more expensive, and the ceiling sat below the real price of every single render. Nothing errored loudly: tasks just refused to start. Lesson: test your guard rails against the real price list, not the one you had in mind when you wrote them.

2. The provider wanted a file extension. The photo links we handed to the provider were clean signed tokens with no extension, and its API answered "file type not supported". Every render was rejected before it started. Now each link ends in .jpg, .png or .webp based on the stored content type, and our own route strips the extension again before it checks the token. Lesson: when an upstream API takes a URL, try it with the exact URL shape you will use in production, not a pretty test link.

3. A fixed daily budget punishes your best day. A hard daily spend cap sounds safe, but on the day traffic finally shows up it starts turning away people who have already paid. Our daily provider budget is now 80% of the credits users currently hold, never above an admin cap. Credits are prepaid, so the budget grows with real demand and still cannot run away.

Do not wake the database for nothing

Our Postgres is on a serverless plan that sleeps when idle and bills compute time. A cron that queries it every few minutes keeps it awake forever. So submitting a task writes an "awake until" timestamp to object storage (two hours ahead), and a reconcile that still sees a running task pushes it forward. The cron reads that one small file first and skips the database once the time has passed.

The result

From the user's side, they click Generate and see a progress state, and a zombie hug AI clip shows up in their library a few minutes later. They can leave the page and come back. From the server's side, no request lasts longer than a database write and one API call.

If you are building anything on top of slow AI models (video, long audio, big batch jobs), the pattern carries over: quote, reserve, submit, reconcile, copy, settle. Keep the uncertain state. You will need it.