Un anno fa ho deciso di puntare tutto sullo sviluppo di app in solitaria. Il mio obiettivo non era solo scrivere codice, ma creare, pubblicare e gestire prodotti reali in modo indipendente.
Dodici mesi dopo, ho creato e pubblicato 5 app distinte sia su App Store sia su Google Play. Guardando la cronologia dei commit e le metriche dei download, emerge una consapevolezza schiacciante su tutte le altre: sviluppare il software è stata la parte facile. Il marketing è stata la vera sfida.
Ecco le più grandi lezioni tecniche e non tecniche che ho imparato in un anno di lavoro in solitaria.
Parte 1: lo sviluppo (dove gli sviluppatori si sentono al sicuro)
Quando sei uno sviluppatore, passare 10 ore in VS Code a configurare la gestione dello stato o a risolvere problemi di build nativa sembra produttivo. È dentro la nostra zona di comfort. Ma pubblicare 5 app multipiattaforma in un solo anno mi ha costretto a ripensare radicalmente il modo in cui sviluppo software.
1. Costruisci un arsenale di infrastruttura personale
Sviluppare cinque app diverse una dopo l’altra mi ha insegnato a non risolvere mai lo stesso problema due volte. Alla terza app avevo creato il mio stack boilerplate interno:
- Framework: React Native / Expo (con Config Plugin per automatizzare il codice nativo iOS/Android).
- Architettura: archiviazione local-first (AsyncStorage) per eliminare la complessità del backend e i costi dell’infrastruttura cloud.
- Integrazioni: hook già astratti per integrazioni native come Apple HealthKit, Google Health Connect e i widget iOS.
Se lavori da solo, la tua velocità è l’unica leva. Un’architettura riutilizzabile significa dedicare l’80% del tempo al valore principale dell’app e solo il 20% alla configurazione.
2. “Local-first” non è solo tecnologia. È libertà
Ogni riga di codice backend che scrivi è qualcosa che devi mantenere, proteggere e pagare mentre dormi. Passare a un’architettura rigorosamente local-first ha significato zero migrazioni di database, zero preoccupazioni per l’uptime dei server e prestazioni istantanee dell’app per gli utenti. In più, agli utenti attenti alla privacy piace che i loro dati non lascino mai il dispositivo.
3. La perfezione è nemica della pubblicazione
La mia più grande trappola da sviluppatore all’inizio era rifinire i casi limite prima ancora di sapere se qualcuno volesse l’app. Alla quarta app ho adottato una regola rigida: pubblica prima il ciclo principale. La rifinitura viene dopo, quando gli utenti reali ti danno feedback.
Parte 2: il marketing (la vera sfida)
Da ingegneri ci piace credere nella meritocrazia: “Se creo un ottimo prodotto, gli utenti arriveranno naturalmente”.
Non arriveranno. App Store e Google Play sono cimiteri di app tecnicamente superiori con 0 download. Capire che il codice è solo il 20% dell’equazione dell’indie hacking è stata la lezione più dura di quest’anno.
1. Abbracciare la distribuzione organica (X e Reddit)
Da sviluppatore solitario senza un grande budget pubblicitario, mi sono concentrato interamente sul marketing organico:
- X (Twitter) per il “Build in Public”: pubblicare frammenti di codice, iterazioni di design dell’interfaccia, screenshot delle tappe e difficoltà tecniche non ha solo attirato i primi utenti, ma mi ha messo in contatto con un’incredibile rete di altri sviluppatori.
- Reddit per feedback basati sul valore: Reddit è brutalmente onesto. Se lasci un link diretto all’app e scappi, verrai bocciato a colpi di downvote. Ma se scrivi post di alto valore che analizzano un problema tecnico complesso, la community risponde con feedback incredibili e primi utilizzatori.
2. Il “marketing nascosto” attraverso la scrittura tecnica
Una delle mie più grandi svolte nel marketing è stata scrivere casi di studio tecnici sulle funzioni che avevo sviluppato nelle mie app. Condividere “Come ho creato un hook unificato per Apple HealthKit / Google Health Connect” sulle piattaforme per sviluppatori ha avuto un duplice scopo: ha offerto valore reale alla community di sviluppatori e, al tempo stesso, ha presentato naturalmente la mia app a persone che apprezzavano il software ben fatto.
3. La regola del 50/50
Se potessi tornare indietro al primo giorno, imporrei la regola del 50/50: dedica il 50% del tempo a sviluppare l’app e il 50% a parlarne, scriverne o migliorare i metadati dello store. Un’app buona con un ottimo marketing batterà ogni volta un’app straordinaria senza alcuna distribuzione.
Considerazioni finali: il cambio di mentalità
Passare da software engineer a creatore indipendente richiede un cambio totale di mentalità. Devi smettere di considerarti solo un “programmatore” e iniziare a operare come product manager, marketer, designer e addetto al supporto clienti, tutto insieme.
Creare 5 app in un anno non mi ha solo reso uno sviluppatore migliore: ha cambiato completamente il modo in cui guardo al software.
A tutti gli sviluppatori solitari che lavorano ancora in segreto: apri l’editor, elimina le funzioni non essenziali, pubblica l’app e inizia a parlarne oggi stesso.