Il bisogno
Per due anni ho usato app per tenere traccia delle spese quasi ogni giorno. L’App Store ne è pieno, molte delle quali più ricche di funzioni rispetto a quella che ho finito per costruire, ma nessuna rispecchiava il modo in cui vengo pagata, il modo in cui spendo e soprattutto il modo in cui tengo traccia delle spese. Continuavo ad adattare le mie abitudini all’app, invece del contrario.
Così, spinta dalla curiosità di provare ad usare Claude per qualcosa di più rispetto ai testi e fogli di calcolo, ho provato a costruire un’app vera e propria.
Dall’idea a un’app che funziona
Sono partita come parto da qualsiasi progetto: dalla ricerca. Ho studiato le app concorrenti, ho messo in fila cosa facevano bene e dove non arrivavano, e da lì ho deciso cosa doveva fare di diverso Flowy. Un’idea è rimasta: seguire le spese rispetto al giorno in cui ti arriva lo stipendio, non rispetto al mese del calendario. Sembra una piccolezza, ma è quello che finalmente fa tornare i conti.
Poi l’ho costruita in SwiftUI, con Claude Code e Xcode: circa un mese di sviluppo, soprattutto nei fine settimana, provandola di continuo nel simulatore di iPhone. È seguito un altro mese di test, prima sui miei dispositivi e poi con beta tester su TestFlight, trovati tra amici e follower. I loro riscontri hanno dato forma a diverse funzioni prima del lancio e mi hanno permesso di capire una cosa fondamentale: l’app funzionava davvero e durante la fase di beta testing non si è mai bloccata, su nessun modello di iPhone.
Cosa ho imparato
Focalizzarsi sul prodotto, tenendo in considerazione vincoli reali. Quando l’app finisce nelle mani di altre persone, è normale che chiedano funzioni che magari ora non ci sono nell’app. Alcune sono brillanti idee, alcune sono idee poco compatibili con l’app, altre sono idee interessanti a cui però devi dire di no. No perché non è il momento, no perché lo sforzo produttivo è troppo grosso in quella fase, no perché soddisferebbe solo una piccola nicchia, ecc. Dire no conta quanto dire sì alle buone idee.
Leggere i dati e agire di conseguenza. Grazie alle statistiche di App Store Connect, alle recensioni, ai feedback e alle segnalazioni di bug di utenti veri, ho imparato a distinguere il segnale dal rumore: un calo di conversioni può significare una cosa da poco, come un pubblico più ampio, oppure un vero problema nella scheda dell’app; un bug capitato una volta può essere un problema occasionale oppure uno schema da correggere prima della versione successiva.
Pubblicare un’app è un altro mestiere. App Store Connect, Xcode Cloud e TestFlight hanno una curva di apprendimento tutta loro, separata dalla scrittura del codice: numeri di versione, build, certificati, linee guida della revisione, tempi di rilascio. Ho imparato tutto da zero.
Lingue e accessibilità non sono un dettaglio da aggiungere alla fine. Far funzionare davvero un’app in una seconda lingua, o con un lettore di schermo, fa emergere dettagli che non penseresti mai di controllare. Alcune delle segnalazioni più utili dopo il lancio riguardavano l’accessibilità.
L’AI come collega, non come scorciatoia. Ho usato strumenti diversi per lavori diversi: Claude Code per costruire l’app e per tutta la pubblicazione sull’App Store, Claude Design per l’interfaccia, Gemini e Perplexity per le prime ricerche, ChatGPT per le prime bozze dell’icona. Nessuno ha sostituito il giudizio: cosa costruire, cosa togliere, quale direzione prendere.
A che punto è Flowy
Flowy è sull’App Store: gratuita, senza pubblicità e senza account, in italiano e in inglese. Ha già diverse recensioni a cinque stelle, e le richieste di funzioni e i feedback continuano ad arrivare e a influenzare un po’ ciò che verrà dopo.
Non è un prodotto finito, e non credo lo sarà mai. Ma è software vero, usato da persone vere, che ho progettato, costruito, testato e pubblicato. E che mi ha permesso di rispondere a un bisogno concreto imparando moltissimo lungo il percorso.