Case study

DRIPT: virtual try-on a un quarto del costo

Il problema

Stavo valutando fornitori esterni per un sistema di virtual try-on. I risultati non erano all'altezza: i prodotti non sembravano veri e la foto caricata dall'utente non veniva rielaborata, il capo era semplicemente incollato sopra. E il conto? Il costo del modello AI, più il margine del fornitore su ogni singola generazione. Stesso stack, prezzo gonfiato.

La soluzione

Un virtual try-on non è poi così complicato da costruire: si riduce al modello, al prompt, a come vengono presentate le foto prodotto e alla velocità di generazione. Così ho costruito DRIPT, un'applicazione Next.js che mette alla prova più modelli sullo stesso capo e sulla stessa persona, e che si integra su un sito con un tag script.

Il risultato

Output realistico, niente capi incollati sopra, e costi trasparenti: si paga il modello e basta, senza strato di ricarico. In pratica circa un quarto di quanto ci avevano quotato i fornitori esterni.

Non un modello, cinque

La domanda che mi ponevo all'inizio era quale modello usare. La risposta è stata smettere di sceglierne uno e costruire il confronto dentro il prodotto.

DRIPT parla con quattro provider e può lanciare fino a cinque modelli in parallelo sulla stessa coppia persona-capo:

  • Gemini 2.5 Flash di Google, il modello predefinito
  • Kling Kolors di Kuaishou, un diffusion model, tramite fal.ai
  • GPT Image 2 di OpenAI, in due profili di qualità
  • FASHN v1.6, un modello dedicato specificamente al try-on

Ogni generazione viene cronometrata per modello. Alla fine non hai un'opinione su quale sia il migliore: hai gli stessi due input passati a cinque motori diversi, i risultati affiancati e il tempo che ciascuno ci ha messo. È un banco di prova, prima che un prodotto.

Il prompt è il prodotto

È qui che si decide se il risultato è credibile, ed è la parte che nessun fornitore ti lascia toccare. Il prompt di DRIPT è lungo migliaia di caratteri ed è diviso in due blocchi, in ordine di priorità.

Primo: bloccare l'identità della persona. Prima ancora di pensare al capo. Il modello riceve l'istruzione di non generare un volto nuovo, di non farne una media, di non "migliorarlo". Forma della mascella, zigomi, altezza della fronte. Naso, larghezza esatta e forma delle narici. Occhi, con il colore preciso dell'iride e l'anello limbare. Nei, lentiggini, cicatrici, fossette, ognuno nella sua posizione. Capelli: sfumatura precisa, ricrescita, eventuali capelli bianchi, riga, volume, ciocche ribelli. Se la persona porta gli occhiali, la montatura resta identica. E il corpo non si assottiglia e non si gonfia.

Il blocco si chiude con una verifica che il modello deve fare su se stesso: questa persona potrebbe guardare l'immagine e dire "quello sono io, non qualcuno che mi somiglia"? Se la risposta non è un sì senza ambiguità, rigenera.

Secondo: riprodurre il capo con fedeltà assoluta. Il prompt dichiara esplicitamente che qualsiasi semplificazione, approssimazione o "miglioramento" è un errore critico. Colore con tonalità, saturazione e valore esatti. Stampe e fantasie con scala, passo e ripetizione identici, non un motivo genericamente simile. Silhouette, lunghezza dell'orlo e delle maniche, profondità della scollatura. E poi i dettagli di costruzione: numero, misura e tipo dei bottoni, posizione e lunghezza delle zip, forma delle tasche, impunture a contrasto, forma del colletto, polsini.

La descrizione del capo non la scrivo io: arriva da un passaggio di analisi visiva che guarda la foto prodotto e la traduce in testo, poi iniettato nel prompt.

Cinque scatti, non uno

Un virtual try-on che restituisce una sola immagine serve a poco: su una scheda prodotto quella foto deve reggere accanto allo shooting ufficiale. Per questo ogni generazione produce cinque inquadrature diverse, ognuna con il suo prompt.

Studio per lo scatto pulito, Detail per il primo piano sul capo e sui dettagli di costruzione, poi tre ambientazioni che mettono la persona in un contesto reale.

Nella schermata dei risultati c'è una lente di ingrandimento: ci si avvicina al tessuto, alle cuciture, ai bottoni. È lo strumento con cui ho giudicato la fedeltà durante le iterazioni sul prompt, ed è rimasto nel prodotto perché è esattamente quello che fa un merchandiser prima di approvare un'immagine. Da lì si esportano tutti i risultati in un archivio zip.

Dall'app al sito: l'integrazione

La parte che trasforma un banco di prova in qualcosa di usabile è l'integrazione. DRIPT espone un widget che si installa con un tag script e due elementi in pagina:

  • uno script da includere una volta
  • un pulsante con lo style code del prodotto come attributo
  • un contenitore dove comparirà il risultato, ripetibile più volte nella stessa pagina

Lo script si porta dietro il proprio CSS, mostra uno scheletro animato durante la generazione e riconosce da solo l'indirizzo delle API dal proprio src. Non serve nessuna chiave nel markup: il server controlla l'header Origin della richiesta contro una lista di domini autorizzati, così nessuna credenziale finisce nel sorgente di una pagina pubblica.

Lo style code è il ponte con il catalogo. Un archivio su Firestore associa ogni codice alle immagini del prodotto, al brand e a un flag di attivazione, con un'area di amministrazione per gestirli. Il pulsante sulla scheda prodotto dichiara solo il codice: tutto il resto lo risolve il sistema.

I conti, fatti davvero

La frase "un quarto del costo" non è un'impressione. Dentro DRIPT c'è un modulo che calcola il costo per generazione modello per modello, con i prezzi presi dalla documentazione ufficiale dei provider e la dichiarazione esplicita di quali numeri sono confermati e quali stimati.

Il calcolo è proiettato su uno scenario di traffico reale: quasi un milione di sessioni al mese con un tasso di interazione del 5 per cento, cioè circa 49.000 generazioni mensili. A quella scala la differenza tra un modello e l'altro smette di essere un dettaglio tecnico e diventa una voce di budget.

Il punto non è che costruirlo costi meno. È che i conti sono visibili: paghi il modello, e sai quanto.

Cosa ho imparato

Il modello conta, le foto prodotto contano, la velocità conta. Ma è il prompt che separa un risultato discreto da uno ottimo, ed è anche l'unica parte che un fornitore esterno non ti lascia mai in mano.

La seconda cosa riguarda l'ordine delle priorità. Quasi tutti i try-on che avevo provato salvaguardavano il dettaglio del capo e sacrificavano la persona. Qui l'ordine è rovesciato: prima si blocca l'identità, poi si riproduce il capo. È una scelta di prodotto prima che tecnica, e si vede nel risultato.

La terza è che costruire ha smesso di essere l'opzione cara. Con un sistema di agenti, un POC di questo tipo non richiede più i tempi e i costi del mondo pre-AI. Quello che prima giustificava un fornitore, oggi giustifica una settimana di lavoro.

In sintesi

Stavo valutando fornitori esterni di virtual try-on: risultati poco credibili, capo incollato sopra la foto, e un prezzo fatto dal costo del modello più il margine del fornitore su ogni generazione. Così ho costruito DRIPT, un'applicazione Next.js che lancia fino a cinque modelli di quattro provider in parallelo sulla stessa persona e sullo stesso capo, produce cinque scatti per generazione e si integra su un sito con un tag script. L'output è realistico e si paga solo il modello: circa un quarto di quanto ci avevano quotato.

Domande frequenti

Cos'è DRIPT e come funziona?

DRIPT è un virtual try-on che ho costruito da zero con Next.js. Prende la foto di una persona e quella di un capo, le passa fino a cinque modelli AI in parallelo (Gemini 2.5 Flash, Kling Kolors, GPT Image 2 in due profili di qualità e FASHN v1.6) e per ogni generazione restituisce cinque inquadrature: Studio, Detail e tre ambientazioni reali. Il prompt, lungo migliaia di caratteri, blocca prima l'identità della persona e poi riproduce il capo con fedeltà assoluta.

Perché DRIPT costa un quarto rispetto ai fornitori di virtual try-on?

Perché si paga il modello e basta, senza lo strato di ricarico del fornitore su ogni generazione. Dentro DRIPT c'è un modulo che calcola il costo per generazione modello per modello, con i prezzi presi dalla documentazione ufficiale dei provider, proiettato su uno scenario di quasi un milione di sessioni al mese e circa 49.000 generazioni mensili.

Come si integra DRIPT su un sito ecommerce?

Con uno script da includere una volta, un pulsante con lo style code del prodotto come attributo e un contenitore dove compare il risultato. Non serve nessuna chiave nel markup: il server controlla l'header Origin contro una lista di domini autorizzati, e un archivio su Firestore associa ogni style code alle immagini del prodotto, al brand e a un flag di attivazione.