A studio’s craft, sold as software.

The studio’s business is the product page: ghost mannequin, flat lay and on-model imagery at four-thousand-pixel resolution, shot under the lighting setups large retailers standardise on. The lighting is standardised. The poses are a known set. The model changes, the garment changes, and everything else is craft that could be encoded.

But a fashion product image has to be true, not merely pretty. The garment must survive generation (fabric texture, print alignment, seams, drape and colour), because a buyer returns a dress that does not look like the picture. The model must be the same model across every angle, or a brand’s catalog falls apart. Hands, fingers and joints must be right. Swimwear and lingerie are a large part of the category and are exactly what most AI services refuse or degrade. And it all has to work on a phone, because brand teams review between meetings.

A generic stack could not hold that. A generation call takes thirty seconds to several minutes on a GPU; a web application that blocks on it locks up and cannot scale. Credits charged before the result comes back mean paying for failures. A single GPU server idles at night and saturates at noon. And a pipeline with the model, the workflow and the application code tangled together cannot be improved without redeploying everything.

The original brief was one dedicated AI model and a try-on system. The business needed a platform.

SCOPE RECONCILIATION

The marketing site is the public face. It carries the positioning, the model catalogue with a page per model, the plans and the path into the portal. Its home page is assembled from content sections the admin edits through the platform’s own API, so the studio can change its story without a developer, and the pages are server-rendered and cached.

The creator portal is where brands work: sign-up, plan selection, the try-on wizard, live job status, output review, history, custom models, credits and billing. A multi-step wizard keeps state locally so a refresh never loses a creator’s place, and a live socket carries job progress with polling underneath it.

The admin is the operations console: the model catalogue, plans and their features, credit packs, add-ons, configuration and the content sections that drive the marketing site.

The API is the single source of truth: authentication, subscription state, credit balances, the job lifecycle, webhook handling and real-time status, never decided in a browser. A separate background worker consumes ten queues for everything that should not happen inside a request.

Three monthly plans (Starter, Growth and Scale) all speak the same currency. A plan grants an allowance and a set of features; higher tiers add upload angles, accessory try-on, 360-degree video, the premium gallery, priority processing and the ability to unlock a custom model. Plans, features and allowances are defined in the admin, not in code, so the studio can change pricing without a release.

Feature access is enforced in two places that always agree: the API checks a plan-feature guard on every gated route, and the portal reads the same feature list and simply does not show what the plan does not include. A creator who reaches a locked feature is taken to the plans page rather than shown an error.

Two nightly jobs keep the ledger honest: one expires credit packs past their one-year life, the other recalculates every creator’s extra-credit balance from the packs that back it and corrects any drift. Both run in the single worker process, precisely so they can never run twice.

The studio can price by outcome rather than by attempt, which is what a brand expects from a studio, and when a creator asks why their balance is what it is, the answer is a list of transactions, not a guess.