Roadmap TALIS — Il Perché della Sequenza

La roadmap non è un calendario di feature. È una strategia di validazione: ogni milestone risolve un'incertezza prima di impegnarsi nella successiva.

Il principio guida: risolvere le incertezze nell'ordine giusto

Ci sono tre tipi di incertezza in un progetto hardware+software+community:

Incertezza tecnica — funzionerà il firmware? L'architettura regge a scala?
Incertezza di prodotto — gli utenti lo useranno davvero? Il comfort del collare è accettabile?
Incertezza di mercato — qualcuno è disposto a pagare? Quanto?

La sequenza delle milestone è costruita per risolvere queste incertezze nell'ordine di costo: prima quelle risolvibili con software (quasi gratuito), poi quelle che richiedono hardware (costoso e lento), poi quelle che richiedono scala (massimamente costoso).

v1.0 — MVP Activity Tracker Cane (in sviluppo)

Perché prima di tutto il resto: Il modulo base BLE + IMU è il cuore di ogni variante futura. Se l'architettura firmware-app-backend non funziona su questo caso semplice, nulla di ciò che viene dopo ha senso. La scelta di iniziare con i pet e non con kids o elderly è deliberata: la barriera etica è minima, il feedback è immediato, la community maker è pronta a testare.

Perché il software prima dell'hardware fisico: Quasi tutto il software del v1.0 è stato completato prima di avere il prototipo fisico. Questo non è un errore di sequenza — è una scelta. Il software si può iterare gratuitamente; ogni ciclo di produzione hardware costa tempo e denaro. Validare l'architettura software per intero prima di toccare il saldatore riduce il rischio delle fasi successive.

Cosa valida questo milestone: Che l'architettura firmware ↔ app ↔ backend funzioni end-to-end. Che un utente reale possa accoppiare un device, vedere la telemetria, e trovare il proprio cane sulla mappa. Tutto il resto è espansione su questa base.

Blocco principale: Il field test su cane reale e il case 3D-printed. Non sono bloccanti per il software, ma sono bloccanti per la pubblicazione della documentazione maker e per la community launch. La sequenza corretta è: hardware → test → docs → community.

v0.0 — Brand & Naming Foundation (parallelo a v1.0)

Perché in parallelo e non prima o dopo: Il brand non richiede hardware funzionante per essere costruito. Logo, palette, tone of voice, domini, social squatting — tutto questo può procedere mentre il firmware viene scritto. Aspettare che v1.0 sia completo significherebbe sprecare mesi.

Perché è importante prima della community launch: Presentarsi alla community maker con un'identità visiva coerente è la differenza tra un progetto serio e un repo GitHub con un README. Il maker valuta la qualità del progetto anche dall'attenzione ai dettagli non tecnici.

v1.0.1 — Safety & Privacy Hardening (patch, pre-maker release)

Perché prima di qualunque release pubblica: Un device che monitori la posizione di un animale (o di una persona) ha obblighi di privacy che non possono essere aggiunti dopo. Il Lost Mode, il Nearby-Only gating, la cancellazione dei dati — questi non sono feature opzionali, sono requisiti minimi per rispettare l'utente. Risolverli come patch prima della maker release significa che v1.0 non viene mai pubblicato in uno stato immaturo dal punto di vista della privacy.

Perché non integrarlo in v1.0: Perché il campo di validazione è diverso. v1.0 valida che il sistema funzioni. v1.0.1 valida che il sistema funzioni in modo sicuro. Mescolare i due obiettivi in un unico milestone rallenta entrambi.

v1.1 — GPS Outdoor (dopo il BLE base)

Perché dopo il BLE e non insieme: Il GPS aggiunge complessità hardware (UART driver, NMEA parser, MOSFET power gating), complessità software (7 colonne GPS nel database, batch ingestion, trail polyline nell'app), e complessità energetica (il GPS attivo può consumare 10× l'IMU). Aggiungere tutto questo a v1.0 avrebbe reso impossibile isolare i problemi durante il debug.

Perché il GPS è necessario prima del LoRa: Il LoRa serve per trasmettere la posizione a distanza; se non c'è una posizione GPS affidabile da trasmettere, il LoRa aggiunge latenza senza valore. La sequenza GPS → LoRa è una dipendenza tecnica hard.

Blocco previsto: Il field test GPS richiede hardware fisico (modulo u-blox, PPK2 per power profiling) e condizioni outdoor. Questo è il primo milestone dove il timing dipende da un acquisto hardware e da condizioni ambientali, non solo dallo sviluppo software.

v1.2 — LoRa Mesh Off-Grid (il differenziatore principale)

Perché è qui che TALIS diventa unico: Nessun competitor nel mercato pet tracker offre comunicazione off-grid via LoRa mesh. Questo è il punto di differenziazione più difendibile — non è replicabile con un aggiornamento software da parte di Tractive o Fi, perché richiede hardware dedicato (modulo LoRa, antenna) e integrazione con Meshtastic.

Perché così tardi nella roadmap: Perché richiede la convergenza di tre componenti maturi — GPS funzionante, hub padrone testato, e rete Meshtastic operativa. Ogni dipendenza ha il suo ciclo di test. Aggiungere LoRa prima che GPS e hub siano stabili significa debuggare tre variabili contemporaneamente.

L'hub padrone: La scelta di sviluppare l'hub in parallelo al LoRa collar module è deliberata. L'hub è il gateway che fa funzionare il sistema off-grid; senza di lui il LoRa collar è un trasmettitore senza ricevitore. Lo sviluppo dell'hub è iniziato già in Phase 21 (documentazione e firmware) per essere pronto all'integrazione quando il hardware LoRa sarà disponibile.

v1.2.1 — UWB Biometric Sensing PoC (gate decision, non feature)

Perché questo non è una milestone di prodotto: È una milestone di ricerca. La domanda è: l'IR-UWB radar (Novelda X4F103) funziona davvero per misurare respiro e battito cardiaco non-contact su animali reali? Se sì, la risposta cambia il design del PCB custom (v2.0) e il pendant elderly (v3.1). Se no, si esclude la feature e si evita di incorporare componenti costosi in un PCB che non può essere modificato.

Perché adesso e non dopo v2.0: Perché il PCB custom si disegna in v2.0. Se la decisione sull'IR-UWB arriva dopo v2.0, significa riprogettare il PCB. Il gate document deve arrivare prima del KiCad layout, non dopo.

v1.3 — Maker Release V1 (il lancio della community)

Perché così tarda rispetto al software: Una maker release non è solo codice funzionante — è codice documentato, testato da persone reali su hardware reale, con una guida di flashing che non presuppone familiarità con PlatformIO, e un troubleshooting guide che copre i 20 casi di errore più comuni. Questo materiale non può essere scritto prima del field test (v1.0 + v1.0.1) e prima che il GPS e il LoRa base siano stabili (v1.1 + v1.2).

CI/CD e OTA qui: GitHub Actions per il firmware build e il DFU OTA via BLE arrivano in v1.3 perché prima non sono necessari — il firmware iterava velocemente durante le fasi precedenti. Introdurre un processo di release management mentre il firmware cambia ogni giorno rallenta lo sviluppo. In v1.3 il firmware è abbastanza stabile da meritare un processo formale.

Kit sales: Il kit pre-assemblato su Tindie/Shopify (€35–45) è il primo punto di contatto commerciale. Viene dopo la documentazione, non prima, perché un kit senza docs è un mattone che l'utente non sa come usare.

v2.0 — Custom PCB v1.0 (da dev board a prodotto)

Perché così tardi: La transizione da XIAO nRF52840 a un PCB custom è irreversibile a breve termine — una volta che il PCB è in produzione, i bug hardware richiedono una nuova revisione con lead time di settimane. Per questo motivo, il PCB viene disegnato solo quando l'architettura software è completamente validata su dev board. Ogni requisito hardware del PCB è già stato testato su XIAO prima di essere inciso su silicio.

Perché Zephyr RTOS in v2.0: PlatformIO/Arduino è stato scelto per iterare rapidamente in v1.x. Zephyr RTOS offre più controllo sul power management, migliore supporto BLE stack, e certificazione CE/FCC più semplice — ma ha una curva di apprendimento più ripida. Affrontarla in v2.0, quando l'architettura è stabile, è meno rischioso che farlo in v1.0 quando tutto è ancora in evoluzione.

v2.1 — Beta Product Launch (50 unità)

Perché 50 e non 500: Cinquanta unità sono abbastanza per validare il processo di produzione (procurement, assemblaggio, QC, spedizione) senza immobilizzare capitale in un inventory che potrebbe richiedere modifiche post-feedback. È il numero minimo per avere feedback statisticamente significativo da utenti reali che hanno pagato.

Perché dopo il PCB custom e non prima: Un beta launch su dev board XIAO è problematico su tre fronti: costo troppo alto per l'utente finale, forma fisica non da prodotto, e l'utente beta testa un'esperienza che cambierà significativamente in v2.0. Il feedback sarebbe parzialmente invalidato dal cambio hardware.

v2.2 — SaaS Cloud & Monetization (il primo revenue ricorrente)

Perché la monetizzazione arriva così tardi: La sequenza corretta è: costruisci qualcosa che funziona → costruisci una community che la usa → mostra che la community è disposta a pagare. Lanciare un SaaS prima di avere utenti reali è un esercizio di ottimismo mal riposto. Il SaaS cloud in v2.2 non è un esperimento — è la conversione di una community esistente in revenue.

Perché self-hosted rimane sempre gratuito: Perché è un impegno filosofico, non una scelta tattica. Eliminarlo o limitarlo retroattivamente distruggerebbe la fiducia della community maker che ha adottato il progetto nelle fasi precedenti. Il SaaS è competitivo per comodità, non per scarsità artificiale.

v3.x — Espansioni Verticali (Kids, Elderly, Trekking)

Perché in quest'ordine: Kids arriva prima di Elderly per due ragioni. Prima, il form factor (bracciale) è più vicino al collar del PET rispetto al pendant elderly. Seconda, il mercato kids ha una maggiore sovrapposizione demografica con i proprietari di pet tech-savvy — sono già nella community TALIS.

Elderly arriva dopo perché richiede la validazione dell'IR-UWB biometrics (gate 23b) e perché la fall detection + SOS handler richiedono un processo di certificazione più attento prima di essere commercializzati.

Trekking arriva per ultimo tra le espansioni consumer perché è il verticale più tecnico, con requisiti hardware più esigenti (high-power LoRa, mappe offline, standalone hub). Ma è anche quello che apre le porte al B2B (soccorso alpino, protezione civile, sicurezza lavoro) — che è il segmento con i margini SaaS più alti.

v4.0 — Scale & Certification (CE/RED, injection molding)

Perché così tardi: La certificazione CE/RED richiede un prodotto hardware stabile e un processo produttivo documentato — entrambi disponibili solo dopo il beta launch (v2.1) e la stabilizzazione del PCB custom (v2.0). Avviare il processo CE prima sarebbe certificare un prodotto che potrebbe ancora cambiare.

L'injection molding (stampa a iniezione) sostituisce il case 3D-printed solo quando i volumi giustificano l'investimento in uno stampo (tipicamente > 500–1000 unità). Prima di quel punto, la stampa 3D è più flessibile e meno costosa.

v4.1 — Satellite & UWB (le feature premium)

Perché satellite e UWB sono le ultime: Iridium satellite e UWB precision finding sono le feature con il costo hardware più alto (Iridium module >> €50) e la domanda di mercato meno provata. Arrivano dopo che il prodotto base ha validato il mercato e generato la community disposta a pagare per funzionalità premium. Non avrebbe senso portare il costo del BOM a €80+ in v1.0 per feature che il 90% degli utenti non userà mai.

Il fattore determinante: hardware vs software

Ogni volta che la roadmap rallenta, il motivo è hardware. Il software può essere scritto, testato e iterato in ore. L'hardware richiede ordini, spedizioni, assemblaggio, strumentazione di test. La roadmap è costruita per massimizzare il lavoro software in anticipo — in modo che quando l'hardware arriva, l'unico lavoro rimasto sia l'integrazione e il test, non la progettazione da zero.

Questo spiega perché al 2026-05-20, con il 44% delle fasi completate, la maggior parte del software delle milestone future (v3.x, v4.x) è già stata scritta in anticipo: fall detection firmware, elderly dashboard, trekking BLE/LoRa bridge, kids UI wireframes, SaaS backend — tutto pronto in attesa dell'hardware fisico.