Snapshot
An AI catalog studio for fashion brands. Upload two or three flat product photos; the platform generates seven catalog-ready shots in different poses, a hero shot at print resolution, and a short product video. A two-day photoshoot collapses into a single upload. Built on top of a customer storefront and a Python/Flask admin console that handles the merchandising side automatically.
Context
Feyntech.AI in-house build. The storefront has since been retired; this case study documents the architecture as it was built and shipped.
The thesis was that fashion brands lose weeks and tens of thousands of rupees per collection to product photography that - at the end of the day - is the same model, the same backdrop, the same poses, over and over. If that's a solvable shape, AI image generation should solve it. The storefront and the admin console exist to make the generation engine useful end-to-end.
Problem
A small fashion brand launching a collection has the same three problems every season:
- Time. A photoshoot is a day on-set plus a week of editing per SKU's worth of shots. A two-hundred-item collection is two months of production before the first product can go live.
- Cost. Studio rental, models, makeup, photographer, editor - every item carries fixed-cost overhead that doesn't scale.
- Iteration. The shots that come back are the shots you get. A pose that reads wrong or lighting that's off means reshooting.
The platform's job is to break that math: take what the brand already has (two or three flat-lay or on-mannequin shots) and produce a catalog-ready set at the speed of a server response, at a fraction of a photoshoot's cost, and editable enough that "reshoot" becomes "regenerate."
A secondary problem: even with the generation solved, the brand still needs to merchandise the output. Two hundred items at launch, each with a colour tag, a category, and a name - most of that has to be derivable from the photo itself.
Approach
AI catalog generation. Two to three input images per product (flat lay or mannequin) become seven catalog shots: hero, three-quarter, full-length, side, and alternate poses. One is rendered at print resolution for use in print catalogues or out-of-home creative. The pipeline calls a generation model, runs face/body consistency checks across the set, and writes the outputs to the brand's catalog. A short product video - model turning, garment in motion - is produced from the same pipeline for use on the product page and on social.
Two tiers, two languages. The storefront is Express + Drizzle + Tailwind + shadcn - fast, typed, deployable to a single Fly machine. The admin console is Python + Flask, because the heavy work it does (image selection, dominant-colour detection, the AI generation pipeline, PDF generation, Drive sync) is more comfortable in the Python ecosystem.
Catalog auto-generation. Drop a folder of source photos in; the admin runs hero selection, dominant-colour detection, AI-shot generation, and PDF preview generation in a single pass. The output is a candidate product list - name, colour, category, gallery - that the team approves before publishing.
Google Drive sync. The team already lived in Drive for product photos. Rather than fight that workflow, the admin reads/writes there directly. Source of truth stays in Drive; the catalog table mirrors it.
PDF as the audit trail. Each catalog batch generates a PDF the team can review on a phone before items go live. The PDF is the artifact a non-technical reviewer signs off on.
Tech
- AI image + short video generation pipeline (Python)
- Storefront: Express, Drizzle ORM, TypeScript, Tailwind, shadcn/ui
- Admin: Python, Flask, Pillow + OpenCV for image work
- Postgres on the storefront, file-based + Drive for the admin
- Deployment: Fly.io for the storefront, Replit for the admin console
What I learned
The best instinct in this build was figuring out what the customer was actually paying for. A fashion brand thinks they're paying for a website - they're actually paying for a photoshoot they can't afford to repeat. Get that input right and the storefront becomes a thin shell around a generation engine. The other instinct: keep the admin console in the language the work fits, not the language the storefront is in. The customer-facing surface should be as boring and fast as possible; the merchandising surface can be opinionated and quirky. They don't need to share a stack.