Soamee.com: 996 pagine in 5 lingue con un team boutique

Il caso di studio più scomodo da pubblicare è il proprio. Non c’è un cliente a cui attribuire il merito né numeri di business altrui dietro cui ripararsi: solo un repository che chiunque può verificare. Questa è la storia di come soamee.com è passato da sito aziendale qualunque a banco di prova della nostra metodologia.

La sfida

Un’agenzia boutique ha un problema di aritmetica. I nostri clienti internazionali arrivano da Spagna, Portogallo, Italia, Germania e dal mondo anglosassone, e ogni mercato vuole leggere nella propria lingua. Il sito che ci serviva non era un sito da cinque pagine: era un catalogo completo di servizi, settori, integrazioni, comparazioni e prodotti nostri, moltiplicato per cinque.

Fatti i conti con il metodo classico, il progetto non tornava. Tradurre e mantenere a mano ogni landing consuma il tempo che dovrebbe andare ai progetti dei clienti, e sappiamo tutti come finisce quella storia: lo spagnolo si aggiorna, il tedesco resta congelato per due anni, e ti ritrovi con un sito che fa peggiore impressione del non avere affatto una versione tedesca.

I tre problemi concreti erano:

• Parità multilingua: ogni contenuto nuovo doveva uscire in cinque lingue o non uscire. Nessuna eccezione «temporanea» che dura per sempre.
• Qualità tecnica costante ad alta velocità: pubblicare in fretta è facile; pubblicare in fretta senza lasciare metadati rotti, immagini fantasma e link morti, no.
• Costo opportunità: nemmeno un’ora del team dedicata a compiti che una macchina può fare e verificare.

La nostra soluzione

Abbiamo applicato a casa nostra la pipeline che usiamo con i clienti: il processo CRAFT (Consult, Research, Architect, Forge, Track) con uno strato di agenti IA sotto e una serie di controlli di qualità automatici sopra.

Le decisioni restano umane

L’architettura del sito, il design system, la tassonomia dei contenuti e il criterio editoriale li ha decisi il team. Gli agenti non scelgono cosa costruire: eseguono ciò che è già deciso. Ogni modifica passa da una revisione umana prima del merge, senza eccezioni.

Lo strato di agenti si occupa del ripetitivo

Dove il lavoro è meccanico e verificabile, deleghiamo:

• Traduzioni in quattro lingue di ogni articolo e ogni landing, con revisione successiva
• Impalcatura delle pagine a partire da template e dati già strutturati
• Migrazioni massive e refactor che toccano centinaia di file in una volta
• Script di controllo e automazioni di CI

I controlli di qualità non si saltano

Qui sta la parte che rende sostenibile la velocità. Ogni modifica attraversa controlli automatici prima di arrivare in produzione, e gli stessi controlli girano in locale tramite un hook di pre-push:

• Copertura delle traduzioni: se un contenuto esce in spagnolo senza le sue quattro traduzioni, il push fallisce
• Verifica delle immagini: ogni immagine referenziata esiste, e due contenuti diversi non riusano lo stesso file
• Audit SEO: title, description, h1, canonical e hreflang di ogni URL costruito
• Validazione di Schema.org: il JSON-LD di ogni template, controllato
• Anteprime social: ogni URL ha la sua card con il suo copy, generata su richiesta

A questo si aggiungono gli audit programmati: Lighthouse, rilevatore di link rotti, guardia sui metadati e snapshot di posizionamento. 22 automazioni in tutto.

Le card social, un esempio dell’approccio

Un dettaglio piccolo illustra bene la differenza. Ogni URL del sito ha la propria anteprima social, con il titolo e la descrizione di quella pagina specifica e con il design della sua sezione. Non c’è una sola immagine salvata nel repository: vengono generate su richiesta con satori e resvg, senza browser, e messe in cache in memoria.

Farlo a mano per mille pagine non è praticabile. Automatizzato, è un template per famiglia di contenuti più un endpoint. È il tipo di lavoro che cambia categoria quando il costo marginale dell’esecuzione crolla.

Risultati

• 996 pagine pubblicate e mantenute, rotte dinamiche escluse
• 5 lingue in parità reale: spagnolo, inglese, portoghese, italiano e tedesco
• 635 articoli di blog (127 originali in spagnolo con le loro quattro traduzioni)
• 130 casi di successo pubblicati (26 casi × 5 lingue), sempre sincronizzati
• 67 componenti di un design system nostro, senza template comprati
• 22 automazioni di CI a sorvegliare traduzioni, immagini, SEO, Schema.org, link e prestazioni

Il dato che ci interessa di più non è il volume ma la parità. Tenere allineate cinque lingue è la prima cosa che abbandona ogni team a corto di capacità: è l’indicatore onesto del fatto che una pipeline funzioni davvero o suoni soltanto bene in una landing.

Cosa non ha funzionato

Pubblichiamo anche le note a piè di pagina, perché un caso di successo senza quelle non vale niente.

Il design visivo originale è stato il terreno in cui abbiamo ottenuto meno aiuto: il generato tendeva al generico e abbiamo dovuto rifarlo a mano finché l’identità non ha funzionato. Le decisioni di prodotto e la logica di business complessa sono rimaste interamente umane e hanno consumato il tempo che ci si aspetterebbe. E nelle prime settimane abbiamo sottovalutato la revisione: senza i controlli di qualità, la velocità produceva debito più in fretta di quanto producesse pagine. Le automazioni sono nate proprio da lì.

Stack tecnologico

• Framework: Astro 5 in modalità ibrida (SSR con @astrojs/node)
• Stili: Tailwind CSS v4 con design system proprio
• Interattività: isole di React dove servono
• Contenuti: Content Collections in Markdown per blog e casi
• Immagini social: satori + resvg, generate su richiesta
• CI/CD: GitHub Actions e deploy su Dokku
• Qualità: verificatori interni in Node eseguiti in CI e negli hook di git