[ diario ]
Il valore che non si vede
12 agosto 2026
Il giorno della consegna, due siti possono sembrare identici. Le stesse pagine, le stesse fotografie, lo stesso menu. Uno è costruito bene e l’altro no, e nessuno dei due lo dice.
La differenza salta fuori dopo, e non a caso: salta fuori il giorno in cui arriva il primo bot che martella il modulo dei contatti, il giorno in cui un cliente apre il sito in valle con due tacche di segnale, il giorno in cui qualcuno chiede dove finiscono i dati che ha lasciato. Sono giorni che arrivano sempre. La domanda è solo se il sito era stato costruito pensando che sarebbero arrivati.
Questo articolo parla di quella parte, che è la meno visibile e la più costosa da aggiungere dopo.
Sicurezza: la parte che si progetta per chi non è invitato
Un sito pubblico riceve visite che non sono visite. Programmi che provano indirizzi, moduli compilati mille volte al minuto, file caricati che hanno l’aspetto di un documento e dentro sono un’altra cosa.
Costruire pensando a loro cambia le decisioni piccole. Un modulo pubblico ha un tetto alle richieste che accetta, e il tetto non conta solo chi chiama ma anche cosa viene chiamato, perché quando un indirizzo riservato finisce in giro l’abuso arriva da mille parti diverse sulla stessa porta. Un file che si carica viene aperto e guardato nei primi byte, perché il nome e il tipo dichiarato dal browser sono un’informazione, non una prova: è il controllo che ferma l’eseguibile ribattezzato in PDF. Le pagine che riguardano il denaro calcolano gli importi sul server, sempre, partendo da quello che è stato salvato: il browser può proporre una cifra, non deciderla. E le chiavi che aprono i servizi non stanno mai nel codice, perché il codice viaggia e le chiavi no.
Nessuna di queste cose si vede. Tutte si sentono, il giorno in cui servono.
Prestazioni: il rispetto per chi ha una linea lenta
Un sito veloce non è un vezzo da tecnici. È il rispetto per chi lo apre da un telefono, in movimento, con una connessione che non è quella dell’ufficio dove il sito è stato disegnato.
Vuol dire non spedire programmi a pagine che non ne hanno bisogno: chi legge un articolo non deve scaricare il motore necessario a compilare un preventivo. Vuol dire tenere i caratteri tipografici sui propri server invece di andarli a chiedere altrove ogni volta. Vuol dire dichiarare le misure di ogni immagine, così la pagina non balla sotto il pollice di chi sta già leggendo, e caricare le fotografie quando servono e non tutte insieme all’apertura. Vuol dire misurare le visite senza cookie, che è più leggero e più rispettoso allo stesso tempo.
Sono decisioni da poche righe ciascuna. Prese tutte, si sommano in un sito che si apre subito anche dove il segnale è quello che è. Non prese, si sommano in un sito che in città sembra a posto.
Conformità: la parte che protegge voi, non noi
La conformità normativa viene raccontata come una noia burocratica, e invece è la parte che risponde alla domanda più semplice che un cliente possa fare: dove finiscono i miei dati, e chi li vede?
Avere una risposta scritta, verificata da chi di mestiere fa il legale e non l’informatico, vale più di qualsiasi rassicurazione a voce. Vuol dire sapere in quale paese stanno i dati raccolti. Vuol dire che le regole su chi può leggere cosa sono scritte nel database e non soltanto nel programma che lo interroga, perché un programma si può aggirare e le regole del database no. Vuol dire un’informativa che dice davvero quello che succede, e un documento che dichiara di non essere una fattura quando non lo è.
È anche la parte che invecchia: una privacy policy scritta bene tre anni fa e mai più riletta oggi descrive un sito che non esiste più.
E adesso la parte scomoda
Tutto quello che avete letto qui sopra si può dichiarare. È la cosa più facile del mondo: si scrive in una pagina di presentazione, si mette in un commento nel codice, si dice in riunione. E una volta scritta, nessuno la controlla più. Diventa vera per abitudine.
Sappiamo per esperienza quanto sia insidioso: una difesa scritta e non verificata è peggio di una difesa assente, perché toglie a tutti la voglia di guardare. Un’immagine che credete oscurata e che invece ha coperto solo il paesaggio, lasciando in chiaro le parole stampate sopra. Un dato strutturato dato per presente da mesi e che non era mai stato scritto. Un errore che il programma si tiene per sé, e che quindi scoprirà il vostro cliente al posto vostro.
Per questo, in bottega, la cura non è un elenco di intenzioni: è un elenco di cose che si possono rifare a comando. Si guarda il sito costruito e non il codice sorgente, perché tra i due c’è di mezzo un compilatore. Si apre l’immagine e la si guarda, perché nessuno strumento di ricerca sa leggere dentro una fotografia. Si misura, invece di ricordare. E quando una verifica trova qualcosa, la prima domanda non è come ripararla ma se la verifica era scritta bene, perché una prova che dà l’allarme sbagliato è tanto dannosa quanto una che tace.
Cosa potete chiedere, a noi e a chiunque altro
Se state valutando un fornitore, la domanda più utile non è “il sito sarà sicuro e veloce?”, perché la risposta è sempre sì. La domanda utile è: come lo dimostrate, e con quale frequenza lo rifate?
Chi ha una risposta vi mostrerà un metodo. Chi non ce l’ha vi mostrerà degli aggettivi.
Da noi la risposta sta in opere, dove le cose che dichiariamo sono elencate una per una in forma verificabile. Se volete la stessa cura sul vostro, raccontateci il progetto.