Note dal primo anno di FitMesh in produzione

FitMesh è online da poco più di un anno. Ecco cosa ho imparato.

Cosa ha tenuto

Lo schema Postgres. L'ho disegnato con un'ora di pensiero in più rispetto al "primo schema che funziona" e mi ha ripagato cento volte. Le query analytics e gli export funzionano ancora oggi senza che debba ristrutturare nulla.

La separazione client/server. Il wearable parla solo con il telefono. Il telefono parla solo con il backend. Il backend parla solo con il database. Niente shortcut, niente API extra. Ogni volta che ho aggiunto una feature, sapevo esattamente dove andava.

Flutter su Wear OS. Era la scelta più rischiosa e mi ha sorpreso: hot reload funzionante anche sull'orologio, performance accettabili, distribuzione via Play Store senza problemi.

Cosa ho riscritto

Il sync layer. La prima versione faceva polling ogni 60s. Aveva senso al lancio (debug più facile), ma non scalava: il telefono si svegliava in continuazione. L'ho riscritto in WorkManager con triggering basato su eventi del Data Layer. Risultato: -70% di consumo batteria sul telefono.

La home dell'app. La prima versione mostrava tutti i dati in un'unica dashboard. Confusionaria. Adesso è una serie di "card" stackate, ognuna con una metrica primaria. Più leggibile, più mobile-friendly.

Un anno di maintenance: cosa assorbe il tempo

C'è una verità che nessun tutorial racconta: spedire l'app è il 30% del lavoro, mantenerla è il 70%.

Wear OS riceve aggiornamenti annuali importanti. Ogni volta tocca riaprire il codice, verificare le API deprecate, testare sul dispositivo fisico. Non è drammatico, ma richiede attenzione e non si può rimandare: se smette di funzionare sull'orologio, gli utenti lasciano una stella e spariscono.

Il Play Store review cycle per ogni rilascio introduce una latenza che al lancio sottovaluto sempre: un fix urgente non arriva in produzione in dieci minuti. Pianificare con anticipo diventa obbligatorio.

Il feedback degli utenti senza un team di supporto è un lavoro a parte. Leggo ogni recensione, ogni segnalazione via email. La maggior parte è preziosa. Alcune richiedono investigazione lunga. Il rischio è passare ore a riprodurre un bug su una configurazione di dispositivo che non possiedo.

Infine, le dipendenze. Ogni aggiornamento di Gradle, Kotlin, o dei plugin Wear OS può rompere la CI in modi non ovvi. Tenere la pipeline verde richiede piccole sessioni di manutenzione regolari, anche quando non stai aggiungendo nulla di nuovo.

Niente di tutto questo è insormontabile. È semplicemente lavoro reale, che non appare nelle demo dei side project.

Cosa cambierei se lo rifacessi oggi

Userei androidx.health.connect.client come livello aggiuntivo dall'inizio
Aggiungerei i grafici trend già nella v1: gli utenti li chiedono da settimana 1
Investirei prima in onboarding: il 40% degli utenti abbandona durante il setup permessi
Non userei Supabase Storage per gli avatar, uno spreco. Una semplice URL + S3 sarebbero più economici

Numeri di contesto

Niente dati segreti, niente bullshit metrics. FitMesh ha utenti veri ma piccoli numeri. Non è il punto. Il punto è che è un esperimento che funziona, è online, è mantenuto, e mi insegna cose ogni settimana.

Un'app indie in produzione vale dieci app indie nel cassetto.