Most "AI product photo" tools do one thing: cut the background out, or generate a lifestyle scene, or write the listing copy. I built Product Studio to chain all three behind a single payment-gated call, because in practice an Etsy or Amazon seller needs all three from the same photo, and doing them as three separate tools means three separate uploads.
product photo → fal-ai/birefnet/v2 (clean transparent cutout)
→ fal-ai/bria/product-shot (lifestyle scene, optional)
→ gpt-4o-mini (SEO listing copy, optional)
birefnet/v2
bria/product-shot
scene_description
and produces the lifestyle shot directly, which is a meaningfully different (and more reliable) task than asking a generalist model to hallucinate a coherent scene around an existing product.gpt-4o-mini
Splitting these three concerns across three purpose-built models instead of trying to get one model to do everything is a smaller version of the same lesson everyone rediscovers with LLM agents: a narrow tool that's good at one thing beats a generalist prompted six different ways.
The lifestyle-shot step doesn't take an arbitrary scene description from the user — it offers four presets (marble
, wood
, studio
, outdoor
), each a fully-specified scene_description
string ("on a clean white marble surface with soft natural window light, minimal editorial ecommerce lifestyle photo, soft realistic shadow"). Sellers know their product; they don't know how to write a compositing model's scene prompt, and a free-text box would mean a much wider variance in output quality for a paid, one-shot generation. Constrained choice beats an open prompt field whenever the buyer's expertise is in their product, not in prompt engineering.
Each of the three stages is wrapped independently: if the cutout succeeds but the lifestyle scene call fails, the user still gets their cutout back rather than a hard error. Only if both image stages fail does the whole request return an error. The SEO-copy failure path is even more explicit — it returns a real result plus a plain-language message pointing the user to support with a refund offer, rather than swallowing the failure silently. On a paid API chain, "one sub-step failed" and "the whole request failed" need to be distinguishable outcomes, or you either refund people who got most of what they paid for, or ship them nothing when you could have shipped two-thirds of it.
Same HMAC-signed payment-grant pattern as the rest of this pipe family: the grant payload carries whether the SEO-copy add-on (grant.c
) was purchased, checked alongside a client-sent wantCopy
flag before the OpenAI call ever fires — so an un-paid request can't trigger the more expensive LLM step even if it asks nicely.
Live tool: https://product-studio-eor.pages.dev/
Happy to go deeper on the fal model chaining or the SEO-copy JSON schema if useful — drop a comment.