Roll-out multi-brand di landing page in PMI: il valore del pre-check
Sto portando cinque landing brand di un'azienda manifatturiera. Dopo le prime fasi, le lezioni più utili non sono di codice ma di workflow: pre-check prima di partire, branch+tag per fase, smoke test SEO automatico, decisioni utente cristallizzate prima del codice.
Sto portando cinque landing brand di un'azienda manifatturiera italiana verso un nuovo design system unificato. Multi-dominio (un sito Vercel, sei domini diversi), nove lingue, theming brand-aware via CSS custom properties scritte SSR sull'attributo data-brand dell'<html>.
Dopo le prime due fasi (foundation theming + landing brand 1 + correzioni successive), le lezioni più utili non sono di codice. Sono di workflow.
1. Pre-check readiness prima di partire una fase
Lo studio architetturale generale aveva detto "due sessioni per brand". In realtà la prima è andata in due sessioni di sviluppo + cinque hotfix iterativi: link al catalog rotti perché il pattern URL non era documentato, listini PDF che cercavano nella cartella public/ locale ma vivevano sul CMS, traduzioni mancanti, banner incoerenti col brand. Ogni hotfix scopriva un'altra incognita.
Per la fase successiva ho lanciato una sessione AI dedicata di pre-check readiness: niente codice, solo audit (asset disponibili, listini esistenti, attributi prodotto, decisioni di tono, rischi). Output: un documento markdown di tre pagine con sei decisioni utente da prendere e cinque rischi specifici con mitigazione. Costo: una sessione. Risparmio atteso: tre o quattro sessioni di hotfix.
2. Decisioni utente cristallizzate prima del codice
Il pre-check produce sei domande secche. L'utente risponde sei volte (anche solo "a, b, a, c, ok, ok"). Quelle risposte diventano vincoli scritti in memoria, e la sessione di sviluppo successiva non ha più nulla da decidere — solo da eseguire.
3. Smoke test SEO automatico
Trenta URL × sei domini × campi <head> (canonical, hreflang, data-brand), tutto in trenta secondi. Snapshot baseline, diff vs nuovo run dopo ogni merge. Se cambia qualcosa di non-atteso, fail. È servito a beccare regression che a occhio non si vedono.
4. Errori ortografici nascosti nei dati
Il bug più sottile della fase: un attributo prodotto si chiamava Applicazione su Allumino — senza la "i" finale. Refuso storico mai corretto. Tre filtri funzionavano, uno no. Non è una correzione del codice, è una documentazione: il pattern URL accettato dal catalog è viscoso, e il fix giusto è descriverlo nella memoria condivisa AI per le fasi successive, non sistemare i dati e rischiare di rompere altri filtri esistenti.
Il roll-out non è finito. Ma il workflow regge: ogni fase produce un tag git, uno snapshot SEO, un documento di lessons learned. Le sessioni AI lavorano in parallelo o in cascata, io coordino. Il valore non è in quanto produce un'AI a singola query — è in quanto produce una serie di sessioni AI specializzate quando un umano fa da arbitro alle decisioni.