Il problema non è generare un'immagine: è generarne trecento uguali
Fotografare una collezione costa: studio, modella, set, post-produzione. Generare le immagini con l'AI sembra la risposta ovvia, finché non ci si accorge che ogni capo esce con una persona diversa e il catalogo non sta in piedi.
Risultati misurati
3
lingue dell'applicazione: inglese, italiano, cinese
3
API: pubblica, interna e di amministrazione
1
orchestratore per tutti i fornitori AI
Stripe
abbonamenti e pacchetti di crediti
01 — Contesto
Un catalogo ha bisogno di coerenza, non di varietà
Chi compra online confronta i capi fra loro: se cambiano modella, luce e posa, il confronto non funziona più e il catalogo sembra un collage. La costanza, in un catalogo, vale più della singola immagine bella.
Il secondo vincolo è il costo: i fornitori di generazione si pagano a immagine, e senza un tetto per cliente una funzione così diventa imprevedibile in bolletta.
02 — Approccio
Un orchestratore in mezzo, e i fornitori dietro
Il prodotto non parla direttamente con i modelli generativi: in mezzo c'è un orchestratore che riceve i lavori, li mette in coda e li affida ai fornitori. Cambiare fornitore — o usarne due insieme — non tocca l'applicazione.
Sopra c'è il conteggio dei crediti: ogni generazione consuma, gli abbonamenti e i pacchetti ricaricano, e il limite è dichiarato prima invece di comparire a fine mese. Sono gli stessi meccanismi che rendono un servizio sostenibile, non funzioni accessorie.
03 — Soluzione
I pezzi del prodotto
Applicazione web
Caricamento dei capi, generazione e libreria delle immagini, in tre lingue.
API pubblica
Un endpoint versionato per chi vuole integrare la generazione nei propri sistemi.
Orchestratore
Code di lavorazione e fornitori AI dietro un'interfaccia sola, sostituibile.
Back office e fatturazione
Amministrazione, abbonamenti, crediti, fatture e gestione dei pagamenti non riusciti.
04 — Dentro il codice
Sessanta documenti di specifica prima del codice
Il repository contiene cinque parti che girano da sole — sito di presentazione, applicazione web, back office, backend e orchestratore — più un SDK in Python per chi vuole integrare la generazione nei propri sistemi. Il backend è la parte più corposa: quasi trecento sorgenti Python fra API, migrazioni e prove.
Prima di tutto questo, però, ci sono sessanta documenti di specifica: visione, architettura, database, API pubblica e interna, fornitori AI, fatturazione, sistema di design. Su un prodotto con tante parti mobili, decidere per iscritto prima di scrivere è ciò che evita di costruire due volte la stessa cosa in modi diversi.
Le prove automatiche sono in due punti — nel backend e nell'orchestratore — perché sono i due posti dove un errore si paga: uno tocca i soldi, l'altro il lavoro che l'utente ha messo in coda.
05 — Risultato
Dove è arrivato
Sito di presentazione, applicazione web, back office, API pubblica e interna e orchestratore sono costruiti; i fornitori di generazione sono per ora simulati dietro la loro interfaccia, che è esattamente il punto: il giorno in cui si collega un fornitore vero, il resto del prodotto non cambia. L'app mobile in Flutter è pianificata.
