Creora — Supplier Photo Cleanup

Turn messy supplier photos into a reviewable, catalog-ready batch.

Comment

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for Creora — Supplier Photo Cleanup

Inspiration

Online stores rarely receive studio-ready product photography from every supplier. The same catalog item arrives with sale badges, old prices, hands, store shelves, collage graphics, watermarks, and unrelated products burned into the frame. Because every reseller receives the same source photo, stores either publish an inconsistent catalog or spend hours rebuilding images manually.

I wanted a workflow that starts where merchants actually work: a folder of files, a list of image URLs, or a supplier product page. It should process a catalog batch, show the source beside every result, charge only for delivered work, and make uncertainty impossible to ignore.

What it does

Creora turns supplier photos into clean, catalog-ready product images in batches of up to 100.

A merchant creates a batch, chooses Clean or the experimental Vary presentation mode, and adds photos from local files, direct image URLs, or supported product pages. Creora normalizes the inputs, queues each photo independently, and processes it with GPT Image 2. The workspace reports progress in real time and keeps the original beside the result for review.

Clean mode removes unrelated overlays and scene clutter and rebuilds the product as a neutral catalog frame. Vary presentation also makes a restrained change to crop, placement, lighting, or composition, but never claims to reveal an unseen side of the product.

The workflow is intentionally honest about generative limitations. Fine print, logos, packaging geometry, and unseen details may change. Merchants are asked to test five representative images first and inspect every result before publication. Accepted results can be downloaded together as a ZIP.

What was new during Build Week

Before Build Week, Creora was a general visual-card and promotional-media generator. Between July 19 and July 21, I used Codex with GPT-5.6 to build and ship the supplier-photo product as a new primary workflow.

The extension includes the GPT Image 2 edit provider, product-photo prompts, batch data models, uploads and product-page import, bounded SSRF-safe remote fetching, asynchronous workers, immutable storage, exact token accounting, retry and cancellation semantics, ZIP export, a new authenticated workspace, a rebuilt bilingual landing page, mobile layouts, and regression coverage for the important failure paths.

The work is documented by the dated branch history beginning at 0ef55b9 and by the primary Codex task (019f79bf-879d-7f60-921d-42cc9cb1dccb).

How I built it with Codex and GPT-5.6

I used Codex running GPT-5.6 across product discovery, architecture, implementation, adversarial review, tests, UI design, deployment, and submission preparation.

Instead of asking for one large code drop, I worked in short vertical slices. Codex first traced the existing billing, storage, authentication, and worker paths. We wrote invariants for token reservation and refunds, provider-call uncertainty, tenant ownership, URL fetching, cancellation, and human review. GPT-5.6 then challenged those assumptions and searched for failure cases before each production rollout.

That process found duplicate-reservation races, crash windows around refunds, unknown external-call outcomes, SSRF bypasses, duplicate imports after partial URL failures, an upload quota that could block a full batch, authentication recovery bugs, and product copy that overstated preservation quality. Each issue became a regression test.

Codex also translated a supplied visual direction into the final responsive landing page and workspace, deployed the application, ran browser checks, and created the English demo with synchronized narration and subtitles.

Technical architecture

The application uses FastAPI, Jinja2, PostgreSQL, SQLAlchemy, Redis, Celery, and MinIO/S3-compatible storage. GPT Image 2 runs through the OpenAI Image Edit API. Pillow normalizes source files and results.

Each photo is a separate item with its own generation audit row and billing run. Tokens are reserved before a task is queued. Completion atomically stores the result reference and captures the reservation. Failure or cancellation uses an idempotent refund scope. If a worker dies during a provider call and the external outcome is unknowable, the system does not retry automatically; it refunds the user and waits for an explicit retry.

Remote intake is resource-bounded and blocks private, loopback, link-local, metadata, and rebinding targets. ZIP manifests are escaped and results never overwrite source objects.

Challenges

The hardest problem was not removing a badge. It was deciding what the product could honestly promise when the entire image is regenerated.

A bottle may remain recognizable while fine label text changes. A box can become cleaner while its perspective or small print is regularized. Creora therefore separates accepted examples from review-required examples and puts the warning inside the workflow rather than hiding it in terms of service.

The second challenge was billing around an external API without an idempotency key. A worker can fail after the provider receives a request but before Creora receives the response. Retrying automatically could create a second provider charge. The final pipeline records an attempt before the call, treats unresolved attempts as unknown, refunds the user, and requires an explicit new billing run.

What I learned

Generative media becomes much more useful when the surrounding workflow is deterministic. Intake limits, immutable originals, per-item status, exact billing, explicit retry, and side-by-side review matter as much as the model prompt.

I also learned that a trustworthy demo includes the failure case. The landing page shows both an accepted perfume result and a drill package that needs review because its fine print and perspective changed. That honest counterexample made the product clearer and the implementation better.

What's next

The next step is a pilot with merchants who regularly receive duplicated supplier catalogs. I want to measure approval rate by product category, learn which packaging types fail most often, and add automatic quality signals that route uncertain outputs to review without pretending to replace human judgment.

Planned product work includes resumable multi-batch catalog jobs, background ZIP preparation, integrations with ecommerce platforms, catalog-level style consistency, and a provenance record linking every published result to its immutable source.

Built With

Share this project:

Updates