u/DryProgress9179

I work on generative product imaging rather than selling POD, so I'm on the tooling side of this, and there's a pattern I keep seeing that I'd like to hear from actual sellers about.

What shows up constantly in seller communities now: the generic AI room mockups and the same handful of framed-print-on-a-beige-wall templates have become common enough that buyers read them as a signal, and the signal is "dropshipper who's never touched this product". Which means someone who genuinely draws their own artwork gets bucketed with the shops copying trends, because both of them used the same mockup pack.

That's a weird failure mode. The mockup was meant to save money on photography and it ends up costing something harder to price, which is the buyer believing the item exists at all.

And the seller side of the tension is real. For a personalised product you can't photograph inventory that doesn't exist. Engraving or printing a sample with someone's name makes it unsellable. So mockups aren't laziness, they're the obvious answer to a genuine problem.

Where I've landed, and I'd like to be argued with here. One photo of one real physical item does most of the trust work even if it's the wrong design, because it answers what a render can't: print density, material, how dark the ink actually goes, edge quality. Make one sample with a generic or common design so it stays plausibly sellable. Mockups then earn their place in later slots showing personalisation variety, ideally captioned as an example rather than presented as a photo. And the honest use of generative tools is taking a real photo and putting that real object in better light or a nicer room, or reformatting it per channel. Real object, better context, not an object that never existed. Blanks are underrated too, since a photo of the undecorated item next to a flat design preview is more convincing than a composite, because there's nothing in it to doubt.

So, questions for people actually selling. Has anyone tested real photos against mockups on the same listing and seen it move conversion, or is this mostly a vocal thing in seller subs that buyers don't actually act on? For those who made physical samples, how many did you need before photos stopped being the bottleneck? And has anyone had a listing reported or pulled over AI imagery, or is that still a policy risk rather than an enforced one?

Trying to work out where the line actually sits for buyers, and you all have better data on that than I do.

Cost-accounting warning for anyone shipping a paid feature on hosted inference, because this cost us three weeks of negative margin and there was no bug anywhere in our code.

We resell generated video inside a paid product. The provider's docs described the model per second, every third-party pricing summary repeated it per second, so I costed per second of output, added margin, charged per second. Modelled around 70%.

Then I stopped reading docs and reconciled real jobs against line items on the provider's own billing dashboard. They meter by output pixel area. Actual numbers: 720p was about 50% margin instead of 70%, and 1080p was negative on every render, which was unfortunate because 1080p was the tier we pushed people toward. Errored jobs billed as well, and returned nothing.

The reason it survived three weeks is more interesting than the mistake. Our cost dashboard was computed from our own duration assumptions, so it could only ever confirm the assumption it was built on. Nothing in the stack compared against dollars the provider actually asserted, so there was no surface where a mismatch could surface. And the cheap tier reconciled perfectly the whole time, so everything looked healthy.

It's not a video-specific trap either. Cache reads and writes priced differently from input tokens (and historically double counted by at least one popular tracing tool). Reasoning tokens billed as output even though the user never sees them. Audio metered per minute of input rather than per token. Image models metered per megapixel or per diffusion step rather than per call. Embeddings billed per token while your code counts documents. Batch tiers that change the multiplier and occasionally the dimension.

What I do now, before a paid tier ships: record the billing dimension per model as data, written out in words, so it's "0.02 per second of 720p output, metered by pixel area" rather than "0.02". Then take one real job on the most expensive tier and find that exact job on the invoice. Docs are a claim, invoices are evidence. Test what happens on failure, since errors, timeouts, retries and partial outputs usually bill and it's usually undocumented. Track cost per accepted output rather than per call, because a 25% discard rate quietly means 4x. Verify the artifact you got back is the one you asked for, since media models will return something shorter or smaller and still charge for the request. And keep unattributed spend as its own visible line, because a cost view with no residual is hiding one.

On sources, since I'm making a general claim off one anecdote: LiteLLM and Langfuse both document that their cost figures are derived from token counts and model price maps rather than provider billing, which is the structural reason those numbers drift from an invoice, and cache-token accounting has been a repeated cause of that drift.

Mostly I'm curious whether anyone here actually reconciles against invoices in their pipeline, or whether everybody is running on estimates like we were. The billing-cycle boundary versus calendar month thing seems like where it gets genuinely annoying.

No pitch and no links, just what I've found. I work on generative imaging for ecommerce, and the question I care about isn't whether a model can make a nice picture, because it can. It's whether the output survives a marketplace's actual requirements and then a real buyer, which turns out to be a much higher bar.

The specs it has to clear, roughly: Amazon wants 1:1 at 1600px or more for zoom, pure #FFFFFF, product filling around 85% of the frame. Flipkart wants 1:1 at 1000px+ and favours model shots in fashion. Myntra wants 3:4 at 1500x2000 and mandates real, gender-matched model imagery. Meesho wants 4:5 at 1080x1350.

What models are genuinely good at now: background replacement and clean white isolation, which is solid and cheap enough to run per SKU. Lighting and scene context, so placing a real product into a plausible environment reads fine. And consistency at volume once you've locked a look, which is the part manual editing is worst at.

Where they still fall over, specifically. Print continuity is the big one. Follow a repeating motif across a fold or a seam and it drifts, and for printed apparel that's fatal because the print is the product. Fabric behaviour at stress points, so shoulder seams, armholes, where cloth gathers at the waist. Generated cloth tends to sit painted-on instead of hanging with weight, and the fold shadows often disagree with the light on the face. Small text and logos come back subtly wrong, which is a trademark problem rather than an aesthetic one. Metal tone and stone facets in jewellery go off, gold turns brassy. And character consistency, which is the one people underestimate most: one good image is easy, the same model across 20 pieces so a product page doesn't look like five different shoots is a different and much harder problem, and most tools don't solve it.

Two practical things people get wrong. Cost isn't metered how you'd assume. Most video models bill by output pixel area, so resolution moves your bill far more than duration does, and failed or discarded generations still bill, so the honest unit is cost per accepted asset. Keep one in four and you're paying 4x sticker.

And policy is a harder wall than quality. Myntra requiring real model imagery means the marketplace a small Indian label most wants synthetic models for is the one most likely to reject them, and better models don't fix that.

Where I've ended up: generation is reliable for everything around the product, so background, per-channel formatting, lifestyle context, silent b-roll. Not yet reliable for anything a buyer judges for physical accuracy, or anywhere the platform requires a real human. Keep one honest photo of the actual product and let the models handle the rest.

If anyone's found a model that holds a print across a fold, I'd like to know, because that's the one I haven't seen handled well in anything released so far.

Building socialshot.ai in public, AI product photography and video for ecommerce brands, paid, solo. Billing went live recently and I'd rather write up the pricing mistakes than the launch numbers, because the mistakes are what I'd have paid to read beforehand.

The first one was priced per second, billed per pixel. We charge for generated video. The provider's docs and every pricing summary I found described the model per second, so I costed per second, added margin, shipped. Around 70% on paper. Then I opened the provider's billing dashboard and read line items for real jobs, and they meter by output pixel area. 720p turned out to be about 50%, and 1080p was negative on every render while being the tier we upsold. Failed generations bill too, and hand the user nothing. Three weeks of that. What's slightly humbling is that nothing in the code was wrong, the unit was, and 720p reconciled fine the whole time which is exactly why it survived.

The second was a hardcoded currency rate that outlived the prices around it. We display USD but charge in local currency for some geographies. When prices changed, one component still had an old per-credit rate baked in from an earlier version, so some customers saw a stale number on one surface while checkout used the real one. Found it by looking at the live site as a customer in that geography, not by reviewing the commit, which had looked complete. The fix that mattered more than the fix: the rate is now computed from one source of truth instead of being a constant repeated across a few files. Patching the symptom would have left three more copies waiting their turn.

Third was subscription credits that never expired. Subscribers got a monthly grant and nothing ever cleared it, so an account could sit dormant for months and then show up with a stack of credits representing real compute I'd have to buy at today's prices. Unbounded liability, growing quietly, invisible in revenue reporting. That one came out of a deliberate audit pass asking what the worst thing a rational user could do with each rule is, rather than testing that the happy path worked. The happy path worked perfectly. That was the problem.

If you're about to charge for model output: write the billing dimension out in words next to the number rather than just the number, reconcile one real job on your most expensive tier against the provider's own invoice before launch, price on cost per accepted output because discards bill, treat any rule that lets a balance accumulate forever as a liability, and go look at your own pricing page as a customer in every geography you sell to, since rendered output is all they ever see.

Happy to go deeper on any of these. Also genuinely curious, for anyone else charging for AI features: did you verify your unit economics against a real invoice, or from the docs? I assume docs is the common answer and I'd like to know I wasn't the only one.

Cautionary tale for anyone building on top of someone else's model API and charging users for the output.

We added AI video generation to our product (socialshot.ai, product photos and video for ecommerce). The provider's docs and every pricing summary I could find described the video model in per second terms, so we did the obvious thing: worked out cost per second, added margin, charged users per second of output. On paper, roughly 70% margin.

Then I opened the provider's actual billing dashboard and read the line items for real jobs instead of trusting the docs. They bill by pixel area, not by duration. Which meant:

720p margin was really about 50%, not 70%.

1080p was negative. Every single 1080p render lost us money, and 1080p was the tier we were actively upselling.

Failed generations still bill. A request that errors and returns nothing to the user is still a charge on our side.

Three things I'd do differently, and would suggest to anyone reselling model APIs.

One: never derive unit economics from documentation, a pricing page summary or a search result. Run one real job of each type and each resolution, then read the invoice line for that specific job. Separately from this, we caught a search snippet that was wrong about a model's price by 15 to 25 times. Docs lag, blogs guess, invoices don't.

Two: price on the same unit your provider bills you on. If they bill by pixel area and you charge by second, you haven't set a margin, you've placed a bet on what resolution your users pick. Worst case is that your premium tier becomes your biggest loss maker, which is exactly what happened here, because the customers who trust you most buy the tier that costs you most.

Three: model your failure rate as a cost, not an exception. If errored calls bill, your effective cost per successful generation is higher than the quoted cost, and it degrades under load, which is precisely when your volume is highest. Also decide upfront what happens when a provider silently gives you less than you asked for. Ours can quietly return a shorter clip than requested, so we had to add verification of delivered output and a pro rated refund, otherwise the customer pays for 10 seconds and gets 6.

The fix in our case was routing the expensive path onto a cheaper variant of the same model. Funny side effect: our premium feature is now more profitable than the standard one.

Same theme on the image side: our image model bills roughly 0.18 to 0.19 dollars per call and also charges for failures. Small numbers that matter enormously when your retail price is cents per image.

Has anyone else been burned by a provider's billing unit not matching its docs? Curious whether this is a video specific mess or standard across the model APIs.

Small thing that cost us months, in case it saves someone here the same mistake.

We launched socialshot.ai. A few weeks later I searched our own brand name and we weren't in the top 20. No penalty, nothing technically broken, no missing sitemap. The reason was much dumber: there is an established product at mysocialshot.com in an adjacent space (AI social and product visuals) that already owned the term. A new .ai domain has close to zero chance against an incumbent with the same name and years of history, on the exact query where you should be unbeatable.

Your brand term is meant to be the one keyword you get for free. If you don't own it:

Every offline mention, podcast, newsletter, Reddit comment or word of mouth referral leaks traffic to someone else, and frequently to a direct competitor. You are doing marketing for them.

You can't measure whether anything is working, because branded search is normally your cleanest attribution signal and now it's contaminated.

Retargeting people who half remember your name simply doesn't happen. They search, they find the other one, that's the end of it.

What I'd check before committing to a name, none of which takes more than 20 minutes:

Search the bare term. Not "yourname ai" or "yourname app", the bare word. Who is on page one, and are they in a related category? An unrelated incumbent is survivable, a related one is not.

Check whether it's a common noun phrase. If it is, you're competing with generic content forever and no amount of link building fixes it.

Check the .com even if you're buying the .ai. Not to own it necessarily, but to see who does and what they sell.

Search YouTube and the app stores too. Different indexes, different incumbents, and those results often outrank your site inside Google as well.

If you've already launched under a contested name, and we have and we're not renaming, the realistic plays are: always pair the brand with a qualifier so the phrase you're actually building equity in is "socialshot ai product photos" rather than the bare word; go hard at long tail category queries where the incumbent isn't present, because that's winnable now; and accept that the bare term is a multi year project rather than a fixable one.

Where we ended up: we now scrape the edge of page two for the contested bare query. That took a programmatic landing page build, a full structured data pass, Search Console and Bing plus IndexNow setup, and weeks of waiting on indexation. That is a lot of work to half rank for your own name. Picking a different name on day one would have been free.

Curious whether anyone here has actually renamed over this, and whether it was worth the churn.