Sviluppo

Sicurezza

Hai un prototipo che "sembra pronto"? Prima di venderlo devi aggiungere queste 3 cose.

Il prototipo "funziona" ma non è vendibile. Prima di lanciare aggiungi: error handling, logging/monitoring, sicurezza e segreti. Checklist finale.

19 febbraio 2026

15 min di lettura

Executive summary

Un prototipo può "funzionare" e allo stesso tempo essere invendibile: basta un errore non gestito, un bug che non sai riprodurre, o un segreto finito dove non doveva.

Prima di mettere utenti reali (e pagamenti reali) dentro il tuo software, servono tre fondamenta: fallback sugli errori, logging/osservabilità, sicurezza minima e segreti.

Perché "sembra pronto" è la frase più pericolosa

Oggi è facilissimo arrivare a un prototipo: lo fai anche con l'aiuto dell'AI, e in poche ore hai interfacce, API, database, login. Ma qui c'è l'inganno: un modello linguistico tende a completare "parti mancanti" in modo probabilistico, cioè genera la continuazione più plausibile dato il contesto.

Questo è potentissimo… finché la realtà entra nel sistema. Perché la realtà ha tre caratteristiche fastidiose:

gli errori succedono (sempre)

i sistemi si rompono in punti che non avevi previsto

se non sai cosa è successo, non lo sistemi: lo peggiori

In mezzo c'è un accelerante moderno: l'AI può produrre codice che "sembra valido" ma può essere semanticamente sbagliato o includere vulnerabilità; perfino le linee guida di tool di AI per sviluppatori insistono su review e test, specie in contesti sensibili.

E c'è anche un tema generale di affidabilità: modelli capaci possono comunque generare output plausibili ma falsi (le famose "hallucinations"), perché spesso gli incentivi di training/eval spingono a "tirare a indovinare" invece di ammettere incertezza.

Quindi: non esiste "software serio" senza fondamenta operative. Non è filosofia. È costo: quando manca qualità interna, ogni nuova feature costa di più e paghi "interessi" sotto forma di lentezza e bug.

Le tre fondamenta che seguono non sono "enterprise". Sono il minimo per vendere senza ritrovarti a spegnere incendi.

Le tre fondamenta

Error handling e fallback

Il prototipo tipico si rompe così: un errore succede, la UI mostra una pagina bianca o un messaggio tecnico, l'utente riprova a caso, e tu non sai neanche da dove partire.

Un prodotto (anche piccolo) si comporta diversamente: quando qualcosa va storto, restituisce una risposta generica e umana all'utente e traccia i dettagli lato server per poter investigare. È esattamente l'approccio consigliato dalle linee guida OWASP sull'error handling: risposta generica al client, dettagli nei log server-side.

Fallback non significa "nascondere i problemi"

Significa evitare che un problema tecnico diventi un problema commerciale.

Esempio pratico (pagamenti): un utente clicca "Paga", la rete va e viene, lui ricarica la pagina, tu ricevi due richieste, e hai il rischio classico: doppia operazione.

Qui servono due cose semplici:

Idempotenza sulle operazioni critiche (creazioni, pagamenti, ordini): un "idempotency key" permette di ripetere una richiesta senza rifare due volte la stessa azione.

Transazioni nel database per mantenere coerenza: o scrivi tutto, o non scrivi niente (commit/rollback).

Non è "teoria": è il modo pratico per impedire che un errore di rete diventi un pasticcio contabile.

Regola da tenere a mente

Se il tuo software tocca soldi o identità, ogni flusso deve rispondere a questa domanda:

"Se succede X (timeout/errore/duplicato), cosa vede l'utente e cosa succede ai dati?"

Se non sai rispondere, non sei pronto a vendere.

Prototipo vs Prodotto: cosa succede quando si rompe

Logging e osservabilità

Quando un prototipo si rompe, di solito succede questo: "da me funziona" e "non so come replicarlo". E spesso è vero, perché senza logging coerente non hai visibilità sul comportamento del sistema.

Una base utile è trattare i log come un flusso di eventi: non "stampare cose a caso", ma registrare eventi significativi in modo consistente. È un principio esplicitato anche nelle pratiche Twelve-Factor: i log come stream di eventi ordinati nel tempo, utili per capire cosa sta succedendo mentre l'app gira.

Logging che ti serve davvero (e non ti mette nei guai)

Due punti fondamentali:

Cosa loggare: eventi di business e tecnici (signup, login, tentativo pagamento, fallimento pagamento, errore DB, timeout API, ecc.). OWASP sottolinea che l'application logging è cruciale sia per casi operativi (debug, performance, monitoring) sia per casi di sicurezza.

Cosa NON loggare: token, session id, password, stringhe di connessione DB, chiavi di cifratura, dati di pagamento e PII sensibile. OWASP lo elenca in modo molto chiaro.

Questa è una differenza enorme tra prototipo e prodotto: il prototipo spesso "logga tutto" (male), il prodotto logga il necessario (bene) e protegge i dati.

Osservabilità: sapere che si è rotto prima che te lo dica un cliente

Logging è una parte. L'altra è accorgerti dei problemi.

Due riferimenti pratici e autorevoli:

La base del monitoring, in ottica SRE, include raccogliere e mostrare dati real-time su errori, latenze, volumi, ecc.

OpenTelemetry definisce l'osservabilità come la capacità di capire lo stato interno di un sistema osservandone gli output (telemetria: log, metriche, trace) e sottolinea che per essere osservabile un sistema va strumentato.

Non devi implementare "enterprise observability" da subito. Ma se vendi, devi almeno poter rispondere in 5 minuti a:

"I pagamenti stanno fallendo?"

"Il login sta andando in errore?"

"Il database sta rallentando?"

Se oggi non puoi, il primo cliente pagante diventa il tuo sistema di alerting.

Sicurezza minima e gestione dei segreti

"Sicurezza" non significa costruire una banca. Significa evitare gli errori più comuni da prototipo che, appena vendi, diventano incidenti.

Una parte enorme della sicurezza minima è banale ma spesso ignorata: segreti e credenziali.

OWASP descrive un problema ricorrente: segreti hard-coded nel codice o sparsi in file di configurazione, con la necessità di centralizzare, gestire ciclo di vita, auditing e rotazione.

E fa un'osservazione che vale oro quando passi da prototipo a prodotto: persino le variabili d'ambiente possono essere accessibili a processi e finire in log o dump, quindi non sono "la cassaforte perfetta"; vanno usate con criterio e, quando possibile, con metodi più sicuri (secret store, mount, fetch in-memory).

Sicurezza minima in pratica: tre cose che fanno la differenza

Segreti fuori dal repository e fuori dai log (API key, DB password, webhook secret, JWT secret).

Autenticazione e autorizzazione non "a sentimento": login non basta, servono regole chiare su chi può accedere a cosa (authorization). OWASP mantiene cheat sheet separati proprio perché sono problemi diversi.

Review e test dell'output AI, soprattutto su parti sensibili: strumenti come GitHub Copilot avvertono che il codice generato può essere inaccurato o introdurre vulnerabilità e che va sempre rivisto e testato, specie in contesti critici.

Questa è la versione onesta del "protitipo AI": funziona finché non tocchi sicurezza, soldi, dati reali. Poi serve mestiere.

Due scenari reali: come si rompe e come si evita

Due scene classiche. Corte. Reali.

Scenario A: pagamenti che "ogni tanto" fanno casini

Versione prototipo (si rompe in faccia):

L'utente clicca "Paga", la richiesta va in timeout, lui riprova. Tu crei due ordini, o peggio due addebiti. Poi arriva l'email: "mi hai addebitato due volte". Tu cerchi nei log e trovi… o nulla, o token e dati sensibili (quindi nemmeno puoi conservarli bene).

Versione prodotto minimo (regge):

Usi idempotency key per tutte le operazioni POST critiche.

Gestisci i dati in transazione (BEGIN/COMMIT/ROLLBACK) così "ordine e stato pagamento" restano coerenti.

Verifichi la firma dei webhook (es. Stripe-Signature + endpoint secret) prima di processare eventi.

In UI mostri uno stato "pagamento in elaborazione" e un fallback umano se qualcosa fallisce (non pagina bianca).

Scenario B: login che funziona in dev e collassa in produzione

Versione prototipo:

In sviluppo va. In produzione fallisce il redirect/il callback. Oppure, per "farlo andare", finisci a copiare incollare credenziali e segreti in un file e poi quel file finisce committato o loggato.

Versione prodotto minimo:

Error handling globale: all'utente dai un errore generico e una via d'uscita (es. riprova, o contatta supporto), mentre tu registri l'errore server-side.

Logging pulito: logghi l'evento "AUTH_CALLBACK_FAILED" con un correlation id, ma non logghi token o sessioni.

Segreti gestiti correttamente, con possibilità di rotazione e senza hardcode.

La differenza non è "più codice". È controllo.

Prototipo vs Prodotto minimo

Quando un prototipo è vendibile e quando è meglio aspettare

Un prototipo può essere vendibile in casi specifici: prova pilota con pubblico piccolo, rischio basso, dati non sensibili, pagamenti magari "manuali" o gestiti con processi controllati (fattura, bonifico, onboarding guidato). L'obiettivo è validare valore, non scalare.

È meglio aspettare (o restringere il perimetro) quando entrano in gioco: pagamenti automatici, dati personali, ruoli/permessi, integrazioni esterne critiche, o qualsiasi contesto in cui un errore diventa perdita di fiducia, tempo e soldi. Perché lì il debito tecnico e operativo cresce velocemente: ogni "scorciatoia" diventa interesse da pagare, come descritto nella metafora del debito tecnico.

La regola pratica: se non hai ancora le tre fondamenta, puoi fare demo. Ma vendere significa assumerti una responsabilità diversa.

Checklist ready-to-sell

Questa checklist è corta e "copiabile". È pensata per un prodotto early-stage: non perfetto, ma vendibile senza auto-sabotaggi. Le aree riflettono pratiche consolidate su error handling, logging/monitoring, gestione segreti e qualità interna.