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 è rileggere i propri appunti con occhi nuovi. 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. Se dipendi da un servizio ne subisci le scelte; se lo costruisci tu, puoi cambiarlo.

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.