Still image or short clip? Deciding feature placement from the cost gap between Nano Banana 2 Lite and Omni Flash

Turn it into a working decision function

Running production on "probably about this much" is the most dangerous place to be. I turned the three items above into a formula and wrapped it in a function that takes asset parameters and returns the recommended medium and a monthly projection. Here is the minimal version I actually keep at hand, as-is.

type MediumInput = {
  monthlyAssets: number;   // new assets delivered per month
  videoSeconds: number;    // seconds per clip if going video
  yieldRatio: number;      // kept / generated. 0.33 = 1 in 3 kept
  editPasses: number;      // avg conversational re-edits per clip
  avgDownloads: number;    // expected downloads per asset
  cdnPerGB: number;        // CDN transfer price (USD/GB)
};
 
const IMAGE_PER_UNIT = 0.034 / 1000; // $/image
const VIDEO_PER_SEC = 0.10;          // $/second
const IMAGE_MB = 0.05;               // assumed still-image size
const VIDEO_MB_PER_SEC = 0.6;        // assumed video size per second
 
function estimate(input: MediumInput) {
  const { monthlyAssets, videoSeconds, yieldRatio, editPasses,
          avgDownloads, cdnPerGB } = input;
 
  // Generation (divide back by yield). Video also bills re-edits by the second.
  const genImage = (IMAGE_PER_UNIT / yieldRatio) * monthlyAssets;
  const videoUnit = VIDEO_PER_SEC * videoSeconds * (1 + editPasses);
  const genVideo = (videoUnit / yieldRatio) * monthlyAssets;
 
  // Delivery (size x downloads x transfer price)
  const gbImage = (IMAGE_MB * avgDownloads * monthlyAssets) / 1024;
  const gbVideo = (VIDEO_MB_PER_SEC * videoSeconds * avgDownloads * monthlyAssets) / 1024;
  const cdnImage = gbImage * cdnPerGB;
  const cdnVideo = gbVideo * cdnPerGB;
 
  const image = genImage + cdnImage;
  const video = genVideo + cdnVideo;
 
  return {
    imageMonthlyUSD: Number(image.toFixed(2)),
    videoMonthlyUSD: Number(video.toFixed(2)),
    ratio: Number((video / image).toFixed(1)),
    recommend: video > image * 20 ? "image" : "video-ok",
  };
}

The crux of this function is that it adds generation and delivery before comparing. Look at generation alone and the still image wins outright; add delivery and the gap narrows. Put the other way, while downloads have not grown, video's delivery cost is still small, so placing a single video on one hero asset is realistic. The recommend threshold — 20x here — is a design value you set from how much cost difference that feature can tolerate. Holding the number as a formula let me debate that threshold as a policy rather than a gut feeling.

Where I actually drew the line with this standard

The primary generation of several hundred backgrounds for the wallpaper app leans, without hesitation, on Nano Banana 2 Lite. You simply cannot put video's unit price on a stage you run at volume on the assumption of throwing most away. This is still image's exclusive territory.

On the other hand, a slot that places a single "image of the day" at the top of the app struck me as worth considering a quiet five-second loop for. This is a slot of maybe 30 clips a month, refined through repeated edits. Feeding the function 30 clips, 8 seconds, 2 edits, and modest downloads, the monthly video figure did not reach hundreds of times the still image; it landed within a range that fit the experience gain of a hero. It breaks if you spread it everywhere, but a single point of luxury holds. That line was the conclusion I drew from the numbers.

It ties cleanly into monetization, too. Assets like video, whose per-unit cost is clearly high, make sense to gate behind a rewarded-ad view or a premium membership. Hand out something that costs an order of magnitude more to everyone for free, and the deeper your downloads run, the deeper the loss. My thinking shifted toward reflecting the cost structure directly in the terms of delivery.

Fold the re-edit cost of conversational editing into the estimate

Omni Flash's signature is conversational editing — swapping characters, relighting a scene, changing the angle, all through natural-language instructions. That the original audio and video tracks are preserved natively is a real advantage when reworking a clip (hold this as a documented behavior and confirm exactly how it lands on your own assets).

From the decision-making angle, though, that ease of editing is simultaneously a cost risk. Each conversational edit incurs another charge by the second. Nudge a 5-second clip "a bit darker," "angle slightly up" three times, and that one clip's effective cost balloons from $0.50 to $2.00. I made editPasses an independent variable in the function above precisely to keep this "the more you fix it, the pricier it gets" property from hiding in the estimate. With a still image, reworking is regeneration at the same unit price; with video, the more you refine, the more the unit cost accumulates. Choose video "because it is easier to adjust" without knowing that asymmetry, and month-end gets you.

I too first saw the ease of editing as a pure advantage. Only after putting editPasses into the formula did it settle that it is both an advantage and a cost amplifier. Touch it, turn it into a number, and only then could I treat it as a design decision — that was the order it came in.

First, fill in this formula once for your own feature

If you have a feature you are stalling over right now — still image or video — put your own operating values into the function above and line up the two monthly figures. How many assets a month, what yield, how many downloads. Filling in just those three tends to reveal that much of the hesitation was a question of order of magnitude, not taste.

Cost design is unglamorous work, but get the order of magnitude wrong and indie development does not last. I am still updating the numbers as I operate, but I would be glad if this helps anyone stalling over the same placement decision. Thank you for reading.