Prodotti con una scadenza scritta nel DNA

La maggior parte del software che costruiamo non ha una data di fine.

Barba Studio esiste finché ha utenti paganti. Il Gestionale Molinari esiste finché ho una partita IVA. Clover, il prodotto di Honeyside, esiste da anni e continuerà finché qualcuno lo compra. L'orizzonte temporale di questi prodotti è indefinito — e quella indefinitezza è normale, è implicita nel modello.

ReD Sposi è diverso. Finisce ad agosto 2026. Non perché smetto di mantenerlo, non perché cambio idea, non perché trovo qualcosa di meglio. Finisce perché il matrimonio è ad agosto, e dopo non c'è più niente da fare.

Questa scadenza biologica ha cambiato ogni decisione che ho preso nel costruirla.

La chiarezza che viene da sapere quando finisce

Il problema più comune nello sviluppo software è l'over-engineering: costruire per casi d'uso che non arriveranno mai, scalare per carichi che non si materializzeranno, aggiungere configurabilità per esigenze future che rimarranno future.

Con ReD Sposi questo problema non esiste.

So quanti utenti ci saranno: qualche centinaio. So quale sarà il picco di traffico: il giorno del matrimonio, probabilmente qualche decina di richieste simultanee al massimo. So quali feature devono esistere: quelle che servono agli invitati per partecipare all'evento. So quali feature sono opzionali: quelle che sarebbero belle ma non cambiano nulla per nessuno il 2 agosto.

Avere questi confini chiari — non come vincolo esterno ma come proprietà intrinseca del prodotto — rende le decisioni molto più semplici. Non devo chiedermi "e se avessimo migliaia di utenti?". La risposta è: non ne avremo. Non devo chiedermi "dovremmo aggiungere questa feature per la versione 2.0?". Non c'è una versione 2.0.

Come ha cambiato le decisioni tecniche

Database: MongoDB su un VPS singolo, senza replica set, senza sharding. Per un prodotto che finisce ad agosto, la disponibilità al 99.99% non è un requisito. Se il server va giù per un'ora durante la preparazione del matrimonio, non è una crisi — è un inconveniente. Ho scelto la semplicità operativa sopra la resilienza teorica.

Auth: Codici invito con JWT a scadenza lunga, come ho scritto di recente. Nessun sistema di recovery, nessuna rotazione dei token, nessuna sessione gestita lato server. Un invitato che perde il codice mi manda un messaggio. Fine.

Feature freeze: Da aprile in poi, nessuna nuova feature. Solo manutenzione, fix di bug reali, e risposta agli invitati. Questa decisione non è difficile quando sai che mancano quattro mesi alla fine del prodotto.

Monitoring: PM2 logs e un webhook Telegram quando il server crasha. Niente dashboarding, niente alerting sofisticato. Se si rompe qualcosa di serio, lo vedo entro un'ora.

Tutte queste scelte sarebbero sbagliate per Barba Studio, che è un prodotto vivo con utenti paganti e una roadmap. Sono giuste per ReD Sposi perché i requisiti di ReD Sposi sono fondamentalmente diversi.

Il rischio opposto

C'è però un rischio nell'altro senso: under-engineering per un prodotto che ha una data di fine prestabilita ma dove il fallimento ha un costo molto alto.

ReD Sposi non può essere flakey il giorno del matrimonio. Non posso permettermi che la chat sia giù mentre gli invitati cercano di mandarsi messaggi, o che la galleria non carichi mentre qualcuno vuole condividere una foto. Non perché ci siano conseguenze professionali — ma perché è il mio matrimonio, ed è un evento che succede una volta sola.

Quindi la scadenza non mi ha dato il permesso di costruire male. Mi ha dato il permesso di costruire esattamente quanto serviva — né più né meno — con quella data in mente come vincolo assoluto di qualità per la finestra temporale importante.

Il prodotto è stabile perché l'ho reso stabile dove contava. Non è scalabile perché non deve esserlo.

La lezione trasferibile

Non tutti i prodotti hanno una scadenza biologica come un matrimonio. Ma molti prodotti hanno orizzonti temporali più brevi di quanto assumiamo — campagne, eventi, prototipi, strumenti interni per un progetto finito.

La domanda utile non è "come costruiamo questo per durare?", ma "per quanto deve durare, e cosa succede alla fine?". La risposta a quella domanda cambia quasi tutto: le scelte di infrastruttura, il livello di polish, la complessità dell'architettura, la quantità di feature da spedire.

Un prodotto che dura un anno e funziona bene per quel anno è un prodotto riuscito. Non è un prodotto fallito perché non dura dieci anni.

Agosto non può arrivare abbastanza presto.