RuttoFacile: PWA mobile-first con Web Audio API, Supabase e sfide virali

RuttoFacile nasce da una richiesta volutamente semplice da spiegare ma meno banale da trasformare in prodotto: registrare un rutto dal telefono, attribuirgli un punteggio e rendere quel risultato abbastanza divertente da essere condiviso e trasformato in una sfida tra amici.

Il mio lavoro ha riguardato l'impostazione tecnica e lo sviluppo dell'MVP come Progressive Web App mobile-first. L'obiettivo non era costruire un classificatore audio scientifico, ma validare un loop di prodotto molto preciso: registra → ottieni il RuttoScore → condividi → sfida un amico → confronta i risultati.

Il problema da validare

Per un prodotto goliardico il rischio principale non è la complessità del database: è costruire troppo prima di sapere se le persone vogliono davvero usare e condividere l'esperienza. Per questo l'MVP è stato progettato attorno a poche domande misurabili: gli utenti completano una registrazione? condividono il risultato? gli amici aprono e completano una sfida? tornano nei giorni successivi?

• Accesso immediato da smartphone senza registrazione obbligatoria.
• Richiesta del microfono solo quando serve, con gestione chiara degli errori e dei permessi negati.
• RuttoScore leggibile e condivisibile come centro dell'esperienza.
• Classifica con il miglior risultato del giocatore invece di duplicare ogni tentativo.
• Battle tramite URL univoco, pensata soprattutto per WhatsApp e condivisione diretta.
• Analytics fin dal lancio per distinguere visite, activation, share rate e conversione delle sfide.

Perché una PWA mobile-first

La scelta di una PWA è legata direttamente al modello del prodotto. Una sfida deve poter arrivare in chat come un normale link: chi la riceve apre il browser e può partecipare senza cercare un'app nello store, installarla e creare un account. Per un test iniziale questo riduce parecchio l'attrito e mantiene più corto il percorso tra condivisione e utilizzo.

Next.js e React permettono inoltre di tenere nello stesso progetto landing, flusso interattivo, pagine delle sfide e parti indicizzabili. Supabase copre database PostgreSQL, identità anonima e persistenza senza introdurre un backend separato più pesante del necessario per questa fase.

La parte più delicata: audio nel browser

Il Ruttometro utilizza il microfono del dispositivo e la Web Audio API per acquisire e analizzare il segnale. È il punto tecnico più sensibile del progetto perché due smartphone possono trattare lo stesso suono in maniera differente: cambiano microfono, guadagno automatico, noise suppression, browser e ambiente circostante.

Per questo ho evitato di presentare il punteggio come una misurazione scientifica. Il RuttoScore è un indicatore ludico costruito su caratteristiche del segnale e controlli di plausibilità. L'architettura lascia spazio a verifiche più avanzate sul riconoscimento rutto/non rutto senza trasformare l'MVP iniziale in un progetto di machine learning molto più costoso.

Dal RuttoScore al viral loop

La schermata del risultato non è il punto finale: è il punto in cui inizia la distribuzione del prodotto. Oltre al punteggio principale, l'esperienza restituisce indicatori secondari e una classificazione ironica; la CTA principale invita poi a sfidare un'altra persona.

• Ogni sfida ha un identificatore e un URL condivisibile.
• Chi riceve il link può entrare nel flusso senza creare prima un profilo tradizionale.
• Il confronto finale collega i due risultati e permette di continuare con una nuova sfida o rivincita.
• La leaderboard aggiunge una seconda motivazione all'uso senza complicare il percorso principale.

Analytics di prodotto, non solo page view

PostHog viene usato per osservare il comportamento lungo il funnel. Per un MVP del genere sapere quante persone visitano il sito è poco utile se non si misura dove si fermano: permesso microfono, registrazione completata, risultato generato, condivisione, apertura della Battle e completamento della Battle.

• Activation rate: quanti visitatori arrivano almeno a un RuttoScore.
• Share rate: quanti risultati generano una condivisione.
• Battle conversion: quante sfide aperte vengono completate.
• Retention: quanti utenti tornano dopo il primo utilizzo, nei limiti di una PWA guest senza account obbligatorio.
• Errori tecnici: permessi microfono, registrazioni non valide e problemi di compatibilità.

Stack tecnico

• Frontend e PWA: Next.js, React, TypeScript e Tailwind CSS.
• Audio: MediaDevices e Web Audio API per acquisizione e analisi del microfono.
• Backend e dati: Supabase con PostgreSQL e autenticazione anonima.
• Hosting: Vercel.
• Product analytics: PostHog; monitoraggio errori predisposto con Sentry.

Le scelte che evitano di sovrasviluppare l'MVP

Una parte importante del lavoro è stata anche decidere cosa non costruire. Per la prima versione non serve una dashboard analytics proprietaria se PostHog copre già il funnel; non serve un account obbligatorio se aumenta l'attrito; soprattutto non ha senso promettere una percentuale di accuratezza del riconoscimento audio senza prima averla validata su dati reali e dispositivi differenti.

• Backend essenziale e schema dati preparato per evolvere senza anticipare tutte le feature future.
• Controlli anti-abuso e di plausibilità proporzionati alla fase del prodotto.
• Nessuna dipendenza da una app nativa per il primo test di mercato.
• Metriche definite prima del lancio, così una eventuale fase 2 può partire dai dati e non dalle impressioni.

Cosa rende questo caso utile anche per altri MVP

Il tema è volutamente particolare, ma le decisioni di prodotto sono comuni a molti MVP: ridurre il numero di passaggi prima dell'azione principale, scegliere una tecnologia coerente con il canale di acquisizione, misurare il funnel fin dall'inizio e separare ciò che serve a validare l'idea da ciò che avrebbe senso solo dopo una prima trazione.