AI SaaS202602 / 06

Fotovyn

An AI product photography and visual content platform for e-commerce sellers, fashion brands, creators, and agencies.

The Fotovyn home page: the headline “Turn one product photo into a full campaign shoot” over a specification table reading input, output, turnaround and supported storefronts.

Role

Founder & sole engineer — AI pipelines, product, platform

Stack

  • Next.js
  • TypeScript
  • Diffusion model APIs
  • Queue workers
  • PostgreSQL
  • Object storage

The problem

Product photography is the single largest recurring cost for small e-commerce sellers — studio time, models, reshoots for every variant. Generic image models get you a nice picture, not a usable catalogue asset with the right product, the right framing and the right consistency across a range.

Approach

  1. 01Built seven distinct visual workflows — studio shots, lifestyle scenes, model try-ons and more — rather than one generic prompt box, so each job runs a pipeline tuned to its output.
  2. 02Grounded generation in the seller's actual product images so the result is their item, not a plausible lookalike.
  3. 03Ran everything through a durable job queue with explicit states, so a slow or failed generation is visible and retryable instead of silently lost.
  4. 04Made cost observable per generation — the platform is only viable if the unit economics stay legible to both the seller and the operator.

System

A generation is a job, not a request. Every submission enters a durable queue with explicit states, so a slow or failed run is visible and retryable rather than silently lost — and every run books its own cost.

  1. Seller

    • Product images
    • Workflow picker
    • Job submission
  2. Edge

    • Next.js route handlers
    • Validation + quota
  3. Queue

    • Durable job queue
    • Explicit job states
    • Retryable failures
  4. Generation

    • Per-workflow pipeline
    • Diffusion model APIs
    • Grounded on the seller's product
  5. Data

    • PostgreSQL
    • Object storage
    • Per-generation cost ledger

Job state streams back to the seller — queued, running, failed, done — so a generation is never a black box with a spinner on it

Trade-offs

What was rejected, and why.

  • Seven distinct workflows, each running its own tuned pipeline.

    Instead ofOne generic prompt box.

    A prompt box produces a nice picture. A catalogue needs the right product, the right framing and consistency across a range — and those are different pipelines, not different prompts.

  • Generation grounded in the seller's actual product images.

    Instead ofText-to-image from a description of the product.

    An ungrounded model returns a plausible lookalike. A seller cannot list a lookalike — it is the wrong item, and it is a returns problem wearing a marketing asset's clothes.

  • Cost tracked and surfaced per generation.

    Instead ofAggregate infrastructure spend reconciled monthly.

    The unit economics have to stay legible to both sides. A per-asset price the seller cannot see is a platform that discovers it is unprofitable a quarter too late.

Outcome

  • Seven production visual workflows in one platform.
  • Catalogue-ready output without booking studio time.

Next project

Menuvyn