Case study · AI product · Fashion
AURA Studio: a photoshoot
from one garment photo.
Small fashion shops need every new piece shown on a person, and a studio day for every drop is out of reach for most of them. This is how I built AURA, an AI studio that puts a garment on a model in about a minute, what sits around the model to make that reliable, and the problems that turned out to be harder than the AI.
The problem
A boutique that sells on Instagram keeps bringing in new pieces, and a piece sells when people can see it on a body. The options were a photoshoot per drop, which most small shops cannot fund, or hanger shots and flat lays, which do not sell the fit.
Image models can already put clothes on a person. What they could not do reliably was the part a shop actually needs: the exact garment rather than a lookalike, the same face from one photo to the next so the feed reads as one brand, a price on the image that is spelled right, and output in the shapes a feed, a story and a reel need.
AURA is built around that gap. The bet was that one photo of the garment and one photo of a model are enough for a finished, post-ready shoot, as long as everything around the model is engineered rather than prompted.
One garment, one model
Real output, unretouched. The first two photos are the entire input, and the other two came from them: the same dress and the same face, in two scenes.
The architecture
Four layers. The image model is a single call inside the second one; everything that makes the result usable sits around it.
1. Shoots are structured, not prompted
A shoot is a set of choices: the model, the pose, the scene, the light, the camera and the output shape. Each one is a preset that code assembles into the request, so the same choices give the same kind of picture and nobody has to learn to write prompts. The garment and the model travel as reference photos, never as a description, because a description is where a model starts improvising. Templates and a guided shoot sit on top of the same presets.
2. Generation runs as background jobs
A photo takes about a minute and a clip takes longer, which outlives a serverless request. Every generation is a job on Trigger.dev: the result lands in the library when it finishes, a render that fails refunds its credits automatically, and the phone gets a push notification the moment a shoot is ready, so nobody waits on a spinner.
3. Text is a layer, not pixels
Image models garble text, and a sale badge with a misspelled price is worse than no badge. Prices, badges and captions are composited afterwards as an editable vector layer, so they stay crisp at any size and can change without regenerating the photo. Every new photo also carries a small AURA watermark by default, removable on paid plans, and every image and video is labeled as AI-made in its metadata, in line with the EU transparency rules that apply from 2 August 2026.
4. One account, two front ends
The web app and the native iPhone app talk to the same backend. The app, built with Expo, uses a versioned mobile API with bearer sessions, so a web release does not break a build already on people's phones. There is one account and one credit balance across both: credit packs bought in the app go through StoreKit 2, every transaction is verified on the server before credits land, and App Store Server Notifications take the credits of a refund back.
The stack
- Application
- Next.js App Router, TypeScript, React
- Data
- Postgres, and S3-compatible storage for every upload and result
- Jobs
- Trigger.dev, for generation runs that outlive a request
- Models
- An image model for photos and a video model for clips, behind one provider layer
- iPhone
- Expo and React Native, StoreKit 2 in-app purchases, push notifications
- Infrastructure
- Vercel
Four things that were harder than the model
The garment drifted
Prints, colors, buttons and logos are exactly where image models improvise. The garment photo is the source of truth and goes in as a reference, never as words, and the presets keep everything else out of its way. It is still not perfect: small prints and logos can drift, so the product says so plainly, and a regenerate costs one credit.
The face changed between photos
A boutique wants one recognisable person across a whole drop, so the feed looks like a brand and not a stock library. The model is a reference photo taken once and reused on every piece, whether it is one of the four house models or the shop's own, so identity is an input rather than something the model has to remember.
A release build crashed on launch
An early iPhone build crashed the moment it opened in TestFlight. The app's JavaScript engine lacks several Intl APIs, one of them was called during the first render, and in a release build that is fatal rather than a warning. A lint rule now bans those APIs, and a root error boundary catches what a rule cannot.
Google crawled the wrong URLs
Most of Googlebot's requests went to the framework's prefetch payloads, each with a fresh cache-busting token, while real pages such as pricing waited to be crawled. Blocking those payloads in robots.txt costs nothing at render time, because a page's first render carries its own data.
What I would keep, and what I would change
Keep: the rule that the image model never draws text. Compositing prices and badges afterwards removed a whole class of embarrassing output and made every badge editable for free. The presets, likewise: they made results repeatable and the product teachable on one screen.
Change: I would build the comparison pages from checked facts on day one, instead of filling a shared template first and checking it later. Every claim about a competitor is now verified on its own site and dated, and each page names the cases where the competitor is the better choice. Template the layout, never the facts.
Also change: I would plan the first App Review as its own milestone. A new developer account is asked for a screen recording on a physical device running the latest iOS and written answers about the app before the review moves, and that round trip belongs in the schedule, not after it.
Frequently asked questions
What is AURA Studio?
An AI photo studio for small fashion brands. You upload one photo of a garment, pick one of four house models or your own model photographed once, choose the pose and the scene, and get finished on-model photos in about a minute, up to 12 at a time, in the shapes a feed, a story and a reel need. Any photo can become a 5, 8 or 12 second vertical video. It runs on the web and as an iPhone app, and the first week is free: 10 photos and a video, no card. I built it, and I run it.
What was the hardest engineering problem?
Not the model. It was making the model's output dependable enough to post: the exact garment rather than a lookalike, the same face on every piece, text that is spelled right, and renders that take a minute without anyone losing a credit when one fails. Each of those is solved outside the model, in presets, reference photos, a composited text layer and background jobs.
Which AI models does it use?
An image model for the photos and a video model for the clips, both behind one provider layer, so either can be swapped for a better one without touching the product. I do not name them, on purpose: models change every few months, and the value is in the workflow around them.
Is there an app?
Yes. The iPhone app went live on the App Store on 17 October 2026. It signs in to the same account as the web, so the library and the credits are the same on both, and credit packs can be bought in the app. There is no Android app yet.
Can you build something similar for us?
Yes, if a model is the core of your product and you need everything around it built properly: the jobs, the storage, the payments, the app, and honesty about what the model still gets wrong. I will also tell you on the call when an existing tool would serve you better than a custom build.
Try it: AURA Studio, AI fashion photography for boutiques is free for a week, and the iPhone app is on the App Store.
Related: MVP development · AI integration · EU AI Act compliant development · the Caldra case study