Case Study · Lumoo

AI fashion visualsfor global brands.

Lumoo is the Nordic AI platform behind the visual content of fashion, sport and retail brands including Gant, Gina Tricot, Johnells, Skobaren and ANWR Group. It started as a Lovable MVP. We picked it up from there and built the real thing: an AI workspace and studio where a brand's own catalog becomes on-model imagery, virtual try-ons and campaign visuals, with Iris, the creative agent, built into it. One fullstack engineer, about a year, still going.

Faster content production: Up to 80%Faster content production
Less CO₂ than sample production: 50-75%Less CO₂ than sample production
Average generation time: 21.7sAverage generation time

Engagement Overview

Lumoo is a Swedish company building the visual content layer for fashion, sport and retail. Their platform makes what a brand’s catalog needs before it needs it: on-model imagery, product shots straight from a design sketch, styled scenes, virtual try-ons and campaign assets, all locked to the brand’s own identity. Gant, Gina Tricot, Johnells, Skobaren, Best of Brands, Holebrook and ANWR Group are on it.

From a Lovable MVP to a full production build. The vision arrived as a prototype with no platform underneath it, and we came in as staff augmentation: one fullstack engineer, embedded in the client’s own team, building the product from the ground up over roughly a year. We are still on it as their engineering team.

The biggest win is Iris, an AI agent built into the product that works like a creative teammate. It creates, researches, watches trends, schedules its own recurring work and connects to virtually any tool a user already works with, which is what keeps the range of what it can do expanding.

Up to 80%
Faster content production: 50-75%
Less CO₂ than sample production: 21.7s
Average generation time

Engagement: Staff augmentation / AI Consulting
Team: 1 Fullstack Engineer
Focus: AI generation pipeline and agent integration
Working model: Inside the client's product team

Stack

Frontend

React
TypeScript
Vite
TanStack Router
TanStack Query
Tailwind CSS
shadcn/ui
Zod
AI SDK

Backend

Supabase
Postgres RLS
Deno Edge Functions
Kysely

Agent (Iris)

Mastra
TypeScript
Gemini
Turso

Data & storage

PostgreSQL
Supabase Storage
Turso

Infrastructure & DevOps

Vercel
GitHub Actions
Playwright
Vitest
Sentry
PostHog

AI & ML

Google
OpenAI
Bytedance
Luma
Replicate

Integrations

Shopify
MCP
Apify
Exa
Resend
Flodesk

A phone held in both hands over a wood table with Lumoo Fit open on it, showing a generated try-on of an outdoor jacket beside the alternate views of the same look

The Challenge

When we started, the client had a product vision and no platform, and the hard part was never a single image render. It was everything that has to exist around one. A render is a request and a result. A product is what happens when a marketing team fires four hundred of them on a Tuesday and expects to know, by name, which ones failed.

Because fashion brands do not generate one image, they generate catalogs. So the system needed bulk pipelines that could take in hundreds of items at once, track every one, retry what failed without dragging the rest down with it, and keep the app responsive while renders ran underneath.

At the same time the image model market changes every few weeks, so nothing could be hardwired to one provider. And Iris could not be a chatbot bolted to the side of the app: it had to drive every generation workflow the platform offers, pick up new capabilities as they ship, and connect to tools that do not exist yet.

The Solution

One pipeline underneath everything, and every creative workflow written as a different question asked of it. What follows is that pipeline at five altitudes: how a single generation runs, how hundreds run at once, what sits behind the model, what a shopper sees at the end of it, and the agent that drives the whole thing on its own initiative.

A generated on-model image in the Lumoo studio: a model wearing a sweater and trousers beside the two catalog product shots the image was generated from

One pipeline, every workflow

Every creative workflow in the platform feeds the same asynchronous generation architecture: on-model imagery, sketch to product, styled scenes, virtual try-on. A request is accepted instantly, rendered in the background, and streamed back the moment it completes. Nothing in the interface waits on a model, which is the property the whole studio rests on. A user queues work, goes and does something else in the app, and watches results arrive.

Designing that first is what made everything after it cheap. Bulk generation is this pipeline with a queue in front of it. Iris driving a workflow is this pipeline with an agent where the person usually is. A new provider is an adapter behind it. The alternative, a synchronous render call written per feature, works beautifully until the first customer imports a catalog, and then has to be taken apart while the product is live.

Async Architecture
Background Rendering
Streamed Results
One Pipeline

Hundreds of items, one job

Bulk generation is what turns the platform from a tool into infrastructure. A brand imports its catalog dynamically, picks what it wants made, and the whole set runs as one job: a queue with per-item tracking, so every product carries its own state instead of the batch carrying one; automatic retries and timeouts, because a provider that stalls on item 217 of 400 must not take the other 399 with it; and direct external exporting at the end, so finished imagery lands where the brand actually publishes.

Per-item state is the unglamorous decision the rest of it hangs on. It is what lets the studio show a catalog filling in live rather than a spinner, what makes a partial failure something you resume instead of something you rerun, and what gives the retry logic anything to be precise about. It is also, in practice, the difference between a brand trusting the system with a whole season and using it for one hero image.

Dynamic Catalog Imports
Job Queue
Per-Item Tracking
Retries & Timeouts
Direct Export

Model-agnostic from day one

The image model market turns over every few weeks, so no model was ever allowed to be load-bearing. Google, OpenAI, Bytedance, Luma and Replicate sit behind a single dispatch layer with one provider adapter each, and the workflows above it do not know which of them served a given request. Swapping a model is a configuration change rather than a refactor, and running two against each other is a normal Tuesday rather than a project.

The dispatch layer is only half of it. The other half is an internal benchmarking harness that proves a new model on real workloads out of the platform's own history before it goes anywhere near a customer's catalog. That distinction matters more here than in most places: a provider's launch benchmarks are measured on general imagery, and this platform is judged on whether a specific brand's specific garment still looks like itself.

Provider Adapters
One Dispatch Layer
Benchmarking Harness
Interchangeable Models

The Lumoo Fit virtual try-on: a selfie and a selected garment combined into an AI-generated result of the shopper wearing a full outdoor jacket and trousers, with size selection beside it

Try-on, and where it ends up

Virtual try-on runs as one more workflow on the same pipeline. A photo of a person and a garment go in, an on-model result comes back. Inside the studio it is how a brand sees a piece on a range of bodies before a sample exists, which is also where the sample-production saving in the numbers above comes from. On a storefront it is Lumoo Fit, the client's own product line, where a shopper sees the garment on themselves before they buy and the brand sees fewer returns.

It is also the workflow that keeps the pipeline honest. Try-on is the one generation a customer's customer looks at, which means it gets judged the way a photograph is judged and not the way a render is. Holding that standard against a queue running hundreds of items in the background is this platform's whole engineering problem stated in a single feature, and it is why the architecture had to be right before the catalog work started rather than after.

Virtual Try-On
AI Body Mapping
On-Model Imagery
Lumoo Fit

Iris, the creative agent built into Lumoo, with the prompt “Turn these sketches into photoreal product shots for our webshop” typed into it

Iris, and the foundation we rebuilt under her

Iris is the creative agent built into the product, and the brief was that she could not be a chatbot. She drives the generation workflows the platform already has, and then keeps going past them: MCP connections to whatever tool a user already works with, self-scheduled recurring tasks so drops and campaigns keep moving without anybody chasing them, and social and web trend research that carries on producing when nobody is at the keyboard. The open-ended layer is the whole point. What Iris can reach is not a list we ever finished writing.

Getting there took rewriting her mid-project. The first version was Python on LangGraph, and scheduling, watchlists and human-in-the-loop approvals all wanted a sturdier foundation than that stack could give us, so the agent moved to TypeScript on Mastra and onto the same language as the rest of the platform. Rewriting a shipped agent halfway through is not a decision anybody enjoys making. It is also the one that let Iris become the thing this product is now known for.

MCP Connections
Scheduled Recurring Tasks
Trend Research
Human-in-the-Loop
Mastra

And the rest of what one engineer carried

The five above are what the platform is demonstrated on. These are what make it something a fashion company can run a season through, and they are also the honest answer to what fullstack means on an engagement staffed with one person.

Catalog and commerce sync
Shopify wired in so products arrive with their own imagery and metadata and finished assets go back out, which is what turns “import your catalog” from a project into a sentence.
The data tier
Supabase Postgres with row-level security, Auth and Storage, so a brand's catalog, its generations and its people are isolated by the database rather than by the application remembering to.
Realtime in the studio
Supabase Realtime carrying results into the interface as they land, which is the visible half of the asynchronous architecture and the reason a four-hundred-item job reads as progress rather than as a wait.
Instrumentation
Sentry and PostHog on the generation paths, because a pipeline spanning five model providers fails in ways nobody is going to reproduce on a laptop.
The delivery loop
Vitest and Playwright running in GitHub Actions onto Vercel, which is what one engineer needs in place to ship a platform this size at this pace and still sleep.
Reach outside the app
Apify and Exa feeding Iris's research, Resend and Flodesk carrying what comes out of it, so the agent's work leaves the platform through the channels a marketing team already uses.

A generated lookbook frame: a model in cream knitwear reclining in a leather and chrome chair against a pale studio wall

Business Impact

The platform is live in production as the client’s entire product. Not a feature of it and not a pilot running alongside something else: what Lumoo sells is what we built. Design, marketing and content teams at fashion brands open it daily to analyse the market, generate imagery, push whole catalogs through bulk jobs and work with Iris.

Engagement has never been higher and it keeps climbing, most sharply since Iris. That is the part we are proudest of, and for a specific reason: in a field that moves under you every few weeks, the usage and the feedback Iris has seen from the moment she was released are the only real evidence that the call on where this was going was the right one. The platform was built to grow into agentic AI rather than be rebuilt around it, and so far it has.