Blog
Build in Public
16 marzo 20268 min

App vocale IA in 650 commit: feedback di uno sviluppatore singolo

Punti chiave: Costruire un gestore di attività vocale con IA da solo significa 650+ commit, una pipeline audio in tempo reale (Deepgram + OpenRouter + OpenAI TTS), un'architettura React Native New Architecture, e soprattutto 6 mesi di lezioni su cosa non fare. Questo articolo copre lo stack completo, gli errori costosi e le decisioni che hanno fatto la differenza.

6 mesi fa, avevo un problema semplicissimo. A casa, eravamo in 4 con pezzi di carta appiccicati al frigo per la spesa. Al club di immersione, tutto passava tramite WhatsApp — impossibile ritrovare un'informazione vecchia di tre giorni. Le app esistenti? Troppo complicate, troppi clic, non adatte alla vita reale.

Oggi, TAMSIV è un'app Android completa con un assistente vocale IA, gruppi collaborativi gerarchici, un'agenda con ricorrenza, gamification, e parla 6 lingue. Più di 650 commit. Sviluppo in solitaria. E ti racconterò esattamente come ci sono arrivato.

Spazio di lavoro dello sviluppatore con schermo di codice React Native, tastiera meccanica e illuminazione blu ambientale
Il mio setup quotidiano durante 6 mesi di sviluppo in solitaria — intere serate a programmare.

Perché creare un gestore di attività vocale nel 2025?

La risposta breve: perché le app di produttività classiche partono dal presupposto che tu sia seduto davanti a uno schermo con entrambe le mani libere. Ma nella vita reale, stai guidando, cucinando, portando a spasso il cane o trasportando la spesa.

Ho testato decine di app — Todoist, Any.do, Google Tasks, Microsoft To Do. Tutte eccellenti sulla carta. Ma nessuna metteva la voce al centro. Magari avevano un pulsante microfono nascosto da qualche parte, ma l'interazione principale rimaneva la tastiera.

La mia scommessa: la voce come interfaccia principale. Premi, parli, l'IA capisce e crea l'attività. Nessun modulo, nessun menu a tendina, nessuna frizione. Se vuoi saperne di più sul perché le app di produttività classiche falliscono, ne parlo in questo articolo sulla fatica delle app di produttività.

Quale stack tecnico per un'app vocale IA?

Scegliere lo stack giusto è la decisione più importante. Ecco cosa ho imparato dopo 6 mesi:

  • Frontend: React Native 0.81 (TypeScript) con la New Architecture (Fabric). Prestazioni native, un unico codebase. La scelta si è imposta perché conosco React e volevo consegnare velocemente.
  • Backend: Node.js/Express + WebSocket. Il WebSocket è indispensabile per lo streaming audio in tempo reale — HTTP non è sufficiente.
  • Database: Supabase PostgreSQL con 3 schemi separati (privat, collaborative, gamification). Spiego questa architettura in dettaglio nel mio articolo sulla strutturazione del database.
  • Sito web: Next.js 16 + Tailwind CSS 4, deployato su Vercel. Ho raccontato la costruzione in 3 giorni in questo articolo dedicato.

Come funziona la pipeline vocale dell'app?

Questo è il cuore tecnico del progetto. L'utente preme il pulsante, parla e riceve una risposta vocale strutturata in 1.5-3 secondi. Sotto il cofano:

Audio PCM 16kHz mono → WebSocket (JWT) → Deepgram STT (VAD) → OpenRouter LLM → Function calling → OpenAI TTS → Risposta vocale
  1. Acquisizione audio: Il telefono invia blocchi audio grezzi in PCM 16 bit, 16kHz, mono tramite WebSocket.
  2. Speech-to-Text: Deepgram trascrive in streaming con rilevamento automatico della fine del parlato (VAD).
  3. LLM: OpenRouter instrada verso oltre 400 modelli con fallback automatico. Il modello comprende l'intenzione e utilizza il function calling per creare attività, memo o eventi.
  4. Text-to-Speech: OpenAI TTS (voce "nova") genera la risposta audio, trasmessa in streaming tramite lo stesso WebSocket.

Ogni fase può fallire indipendentemente. Ho implementato retry intelligenti, circuit breaker e fallback a ogni livello. Per i dettagli tecnici completi della pipeline, leggi l'articolo dedicato alla pipeline vocale.

Mano che tiene uno smartphone con visualizzazione dell'onda vocale sullo schermo, riflessi di luce blu
L'interazione vocale al centro dell'esperienza utente.

Quali funzionalità hanno richiesto più lavoro?

In oltre 650 commit, alcune funzionalità hanno assorbito intere settimane. Ecco la top 3.

I gruppi collaborativi gerarchici

Sulla carta: "aggiungi gruppi". In realtà: un sistema gerarchico a 6 livelli di profondità con 4 ruoli (Admin, Manager, Member, Viewer), query ricorsive PostgreSQL (CTE) e 31 politiche RLS da scrivere e testare individualmente.

Il mio club di immersione è stato il caso d'uso perfetto: Club → Commissione Tecnica → Livello 1 → Gruppo del martedì. L'ereditarietà dei permessi tra i livelli è stata il vero rompicapo. Ne parlo in profondità nell'articolo sui gruppi gerarchici.

L'agenda con ricorrenza

Gli LLM non sono bravi con le date. Quando dici "ogni martedì alle 14:00", il modello deve capire la ricorrenza, il fuso orario e generare le occorrenze corrette. Ho dovuto costruire una tabella di corrispondenza e un sistema di validazione robusto. Il dettaglio tecnico è nell'articolo sull'agenda e i filtri.

La gamification

12 livelli, 10 badge, streak fino a 365 giorni, sfide quotidiane e una classifica. Uno schema dedicato con 5 tabelle e trigger automatici. La gamification non è un gadget — cambia fondamentalmente l'engagement degli utenti. Ho dettagliato l'architettura nell'articolo sullo schema di gamification.

Quali errori evitare quando si sviluppa in solitaria?

Sarò onesto: ho commesso errori costosi. Se stai sviluppando un progetto da solo, impara dai miei fallimenti.

Errore n°1: Zero marketing per 6 mesi

650 commit e nemmeno un post per parlarne. Nessuno. Ero così assorbito dal codice che ho completamente ignorato la parte di visibilità. Il giorno in cui ho voluto comunicare, partivo da zero — zero pubblico, zero contenuti, zero storico.

La lezione: inizia il marketing dal primo commit. Anche un semplice tweet "sto iniziando un nuovo progetto" è meglio del silenzio.

Errore n°2: Sottovalutare l'internazionalizzazione

Passare dal 100% francese a 6 lingue (FR, EN, DE, ES, IT, PT) ha coinvolto 35 file e 1993 chiavi di traduzione. È un lavoro enorme quando lo fai a posteriori. Oggi, ogni nuova funzionalità viene tradotta fin dall'inizio. L'i18n è diventato un vero canale di acquisizione — ne parlo in questo articolo sull'i18n come leva di crescita.

Errore n°3: Non strutturare il database fin dall'inizio

Ho avuto la fortuna di fare questa scelta correttamente, ma ho visto così tanti progetti in cui tutto è nello schema public che lo menziono. Tre schemi separati dal giorno 1, cambia tutto per la manutenibilità. Il dettaglio è nell'articolo sulla ristrutturazione del database.

Sala server moderna con cavi di rete luminosi e rack di server, illuminazione blu cinematografica
L'infrastruttura backend che fa funzionare la pipeline vocale in tempo reale.

Come gestire un progetto in solitaria di questa portata?

650 commit in 6 mesi, fa una media di 3-4 commit al giorno. Alcuni giorni ne facevo 10, altri zero. Ecco cosa mi ha aiutato:

  • Commit atomici: ogni commit fa una sola cosa. Questo rende il debug e il revert molto più semplici.
  • Un monorepo: frontend, backend e sito web nello stesso repository. Un unico git log per vedere la cronologia completa del progetto.
  • Servizi singleton: ConversationService, CalendarService, GamificationService... ogni dominio ha il suo servizio dedicato, facile da testare e mantenere.
  • Il pattern PendingCreation: la voce crea un'anteprima, l'utente convalida, modifica o annulla prima del salvataggio nel database. Zero sorprese.

Qual è il costo di funzionamento di un'app vocale IA?

Domanda che tutti pongono. Ecco la scomposizione per interazione vocale:

  • STT nativo (dispositivo): gratuito. Deepgram cloud come fallback: ~$0.0059/min.
  • LLM tramite OpenRouter: variabile a seconda del modello, tipicamente $0.001-0.01 per richiesta.
  • TTS OpenAI: ~$0.015 per 1000 caratteri.
  • Supabase: piano gratuito generoso, poi ~$25/mese in Pro.
  • Backend Railway: ~$5-10/mese a seconda dell'utilizzo.

In totale, un'interazione vocale completa costa tra $0.01 e $0.03. È sostenibile con un modello freemium — ho dettagliato i livelli di abbonamento nell'articolo su RevenueCat e gli abbonamenti.

A che punto è il progetto oggi?

TAMSIV è in alpha sul Google Play Store. 12 tester attivi. Il lancio in produzione pubblica è imminente.

Le metriche che contano:

  • 650+ commit sul monorepo
  • 6 lingue supportate (FR, EN, DE, ES, IT, PT)
  • 3 modalità WebSocket (Live, Realtime, Batch)
  • 31 politiche RLS per la sicurezza dei dati
  • 12 livelli di gamification con badge e streak
  • 6 schede: Registratore vocale, Feed, Agenda, Gruppi, Social, Profilo

FAQ

Quanto tempo ci vuole per costruire un'app vocale IA da soli?

Per TAMSIV, ci sono voluti 6 mesi a tempo pieno. La sola pipeline vocale (STT + LLM + TTS) ha richiesto circa 3 settimane. I gruppi collaborativi e la gamification hanno aggiunto 2 mesi ciascuno. Se ti concentri solo sull'MVP vocale, calcola 2-3 mesi.

Perché React Native piuttosto che Flutter o nativo?

Conoscevo già React. La New Architecture (Fabric) di React Native 0.81 offre prestazioni quasi native. Flutter era un'opzione valida, ma l'ecosistema npm e la comunità React hanno fatto pendere la bilancia. Il nativo puro avrebbe raddoppiato il tempo di sviluppo senza vantaggi significativi per questo tipo di app.

Lo Speech-to-Text nativo è buono quanto Deepgram?

Per la maggior parte dei casi, lo STT nativo del dispositivo è sufficiente e gratuito. Deepgram eccelle in ambienti rumorosi e per le lingue non europee. TAMSIV utilizza il nativo per impostazione predefinita e passa a Deepgram come fallback. Ho confrontato i due in dettaglio nell'articolo STT nativo vs Deepgram.

Come monetizzare un'app vocale IA senza far esplodere i costi?

Il modello freemium con limiti giornalieri sul piano gratuito. Le funzionalità costose (STT cloud, generazione di immagini IA) sono riservate ai piani Pro e Team. RevenueCat gestisce gli abbonamenti in-app. Il segreto è ottimizzare il costo per interazione — lo STT nativo gratuito copre il 90% degli utilizzi.

È necessario un backend per un'app vocale o tutto può girare in locale?

Hai bisogno di un backend per l'LLM (function calling, orchestrazione) e il TTS (le API sono lato server). Lo STT può girare in locale. Il WebSocket è indispensabile per lo streaming in tempo reale — le chiamate HTTP classiche aggiungono troppa latenza.