Perché sviluppo software indipendente: dal Commodore 64 a oggi

Dieci anni, un cursore lampeggiante

La mia prima macchina è stata un Commodore 64. Non c'erano app store, non c'erano framework, non c'era Stack Overflow: c'era un prompt READY. e un manuale. Se volevi che la macchina facesse qualcosa, gliela insegnavi tu — in Basic prima, e poi, quando il Basic diventava troppo lento, in linguaggio macchina^[1], scrivendo direttamente nei registri del processore.

Quell'imprinting non se n'è mai andato. Chi ha imparato così porta con sé due convinzioni: che ogni macchina è comprensibile fino in fondo, se hai la pazienza di scendere abbastanza in basso; e che tra te e il risultato non serve nessun intermediario obbligatorio. Sono le due convinzioni su cui è costruito tutto Survival Apps.

La deviazione che non era una deviazione

Poi la vita ha preso un'altra strada, apparentemente: laurea in Scienze Biologiche, dottorato di ricerca in Farmacognosia^[2], anni di lavoro in settori diversi — automotive, assicurazioni, farmaceutico. Il codice è rimasto sempre lì, hobby serale e strumento di lavoro non dichiarato, da Windows fino al trasloco definitivo su Linux.

Col tempo ho capito che non era una deviazione. Il metodo scientifico e la programmazione sono lo stesso mestiere con materiali diversi: formuli un'ipotesi, costruisci un esperimento, osservi cosa succede davvero — non cosa vorresti che succedesse — e documenti tutto, inclusi i fallimenti. Un bug è un esperimento con un risultato inatteso. Un refactoring è una revisione della letteratura. Questo blog applica quel metodo in pubblico.

Che cosa significa "indipendente"

Indipendente non significa fare tutto da soli per principio. Significa scegliere strumenti e architetture che restano nelle tue mani anche quando il contesto cambia. Negli anni ho visto troppe volte lo stesso film: un servizio "gratuito per sempre" che chiude, un'API che cambia prezzo di dieci volte, una piattaforma no-code che deprecca la funzione su cui avevi costruito il flusso di un cliente. Chi dipende, subisce. Chi costruisce, si adatta.

In pratica, per me, l'indipendenza si traduce in criteri molto concreti:

• ESSENZIALITÀ — la dipendenza migliore è quella che non aggiungi. HTML, CSS, JavaScript vanilla dove basta; Python e Flask dove serve un server; SQLite dove servono dati persistenti
• LEGGIBILITÀ NEL TEMPO — il codice deve essere comprensibile tra cinque anni, da me o da chi verrà dopo, senza dover ricostruire un ecosistema estinto di tool di build
• DATI PORTABILI — un file SQLite si copia, si legge, si ispeziona con strumenti standard. Nessun formato proprietario, nessun database che vive solo dentro un servizio
• DEPLOY RIPRODUCIBILE — ogni progetto deve poter rinascere su una macchina nuova partendo dal repository e da un README, senza passaggi tramandati oralmente
• ERRORI DOCUMENTATI — il portfolio include ciò che è andato storto. È lì che si vede come lavora davvero una persona

Domande frequenti

Cosa significa "sviluppatore indipendente" in questo contesto?

Scegliere strumenti e architetture che restano nelle tue mani anche quando il contesto cambia — non dipendere da un servizio "gratuito per sempre" che può chiudere o cambiare prezzo da un giorno all'altro.

Che stack tecnico usa Survival Apps?

HTML, CSS e JavaScript vanilla dove bastano; Python e Flask dove serve un server; SQLite dove servono dati persistenti — sempre puntando su essenzialità e dati portabili, come nel case study della dashboard personale.

Che rapporto c'è tra la formazione scientifica dell'autore e la programmazione?

Lo stesso metodo con materiali diversi: formulare un'ipotesi, costruire un esperimento, osservare cosa succede davvero e documentare tutto, fallimenti inclusi.