$263 of my vercel bill was image optimization, not compute Serverless Pricing

You have correctly identified the fundamental mismatch. Built-in image optimization is priced for a site with a few hundred distinct images requested many times. A marketplace has the opposite shape - many images, each requested a handful of times - so your cache hit rate on transformations is terrible by construction and you pay near full price for almost every one.

Three things, in order of effort:

Cut the variant count. Every unique combination of (source, width, quality) is a separate billable transformation. Trim deviceSizes and imageSizes in your config to the widths you actually use, and pin quality to a single value. Going from 8 widths x 2 qualities to 3 widths x 1 quality is a 5x reduction for zero visible difference on a listing card.

Raise the cache TTL. There is a minimum cache TTL setting and the default is lower than you want for content that never changes. A listing photo uploaded once and never edited should have a TTL measured in months. If the cached transform expires, the next request pays for it again.

Transform at upload, not at request. This is the real answer for UGC. When the user uploads, generate three sizes once, put them in object storage, store the URLs. Then serve them as plain images with unoptimized set. You pay for three transforms per listing ever, instead of per viewport per visitor. For 9,000 listings that is 27,000 operations total, once.

If you want to keep the image component's ergonomics - the layout behaviour, the lazy loading, the blur placeholder - you do not have to give it up. Point it at your own transform endpoint with a custom loader:

// next.config.js
images: { loader: 'custom', loaderFile: './img-loader.ts' }

The loader is a function that takes { src, width, quality } and returns a URL. Return one pointing at your own worker or CDN transform service. Same component everywhere, completely different billing.

That is the migration path I would take: loader first so nothing in your components changes, then move the actual resizing wherever you want it.

Check minimumCacheTTL specifically before doing anything bigger. The default is short, and for immutable user uploads that means you are re-paying for the same transformation on a schedule forever. It is one line and it might halve the number on its own.

Optimized images are cached permanently after the first request, so this cannot be transformation volume unless your cache is being purged. I would look for a deploy hook or a revalidation call that is clearing the image cache on every deploy.

Also worth confirming what actually counts as billable on your plan - transformations, cached reads, or both - before you optimise the wrong metric. The line item names on the invoice map to specific things and the difference between "how many unique transforms did I create" and "how many optimized images did I serve" changes which fix helps.