Cos’è il software local-first? Definizione, 7 proprietà ed esempi reali (2026)

Q: Notion è local-first?

No, Notion non è local-first. Notion è un’applicazione cloud-first: la copia autorevole di ogni pagina vive sui server di Notion, e le app desktop e mobili sono client che leggono e scrivono su quei server. Se il cloud di Notion non è raggiungibile, le app si degradano: le funzioni smettono di funzionare, la sincronizzazione si ferma, e il tuo unico accesso è ciò che era in cache. Chiudere il tuo account Notion significa perdere l’accesso ai dati, anche se hai esportato uno ZIP in Markdown, perché i database relazionali, le formule, i blocchi sincronizzati e gli incorporamenti non sopravvivono all’esportazione.

Q: Figma è local-first?

No, Figma non è local-first. Figma è uno strumento di design collaborativo cloud-first: i file vivono sui server di Figma e l’applicazione è un client nel browser o incapsulato in Electron. La modifica multiutente in tempo reale di Figma è costruita sull’operational transformation tramite un server centrale, non su strutture di dati local-first senza conflitti. Figma ha un supporto offline limitato (puoi continuare a modificare per poco un file se era già aperto), ma l’architettura di fondo ha il server come riferimento.

Q: Google Docs è local-first?

No, Google Docs non è local-first. Google Docs è cloud-first. Il documento vive nell’infrastruttura di Google; l’editor nel browser è un client leggero. La modalità offline tiene in cache i documenti recenti per modificarli senza connessione, ma il cloud resta la fonte di verità: le tue modifiche vengono unite sul server, non sul tuo dispositivo.

Risposta rapida. Il software local-first è una categoria di applicazioni in cui i dati dell’utente vivono principalmente sul suo dispositivo, non su un server remoto. La sincronizzazione cloud è facoltativa, non obbligatoria. Il termine è stato coniato in un saggio del 2019 di Ink & Switch, che elenca sette proprietà: veloce, multi-dispositivo, utilizzabile offline, collaborativo, longevo, privato e di proprietà dell’utente. Filarr, Obsidian, Linear e Anytype sono app local-first.

Quando usi Notion, le tue note vivono sui server di Notion. Quando usi Google Docs, il tuo documento vive sui server di Google. L’app sul tuo schermo è una finestra su un database remoto: chiudi la scheda, perdi la connessione, e il tuo lavoro se ne va con lei.

Il software local-first rovescia questo presupposto: i tuoi dati vivono prima di tutto sul tuo dispositivo. Il cloud, se c’è, ha un ruolo di supporto.

Questa guida dà la definizione precisa, ripercorre le sette proprietà del saggio originale di Ink & Switch, distingue il local-first dall’offline-first (spesso confusi) e passa in rassegna le app che nel 2026 lo sono davvero.

Cos’è esattamente il software local-first?

Il termine «local-first software» è stato coniato in un saggio del 2019 dai ricercatori di Ink & Switch: Martin Kleppmann, Adam Wiggins, Peter van Hardenberg e Mark McGranaghan. Lo hanno definito come un software che «ti permette di collaborare senza rinunciare alla proprietà e al controllo dei tuoi dati».

In pratica, un’app local-first:

Conserva i tuoi dati come normali file sul tuo disco locale
Funziona completamente senza connessione a internet
Continua a funzionare se lo sviluppatore chiude o il cloud scompare
Può sincronizzarsi con altri dispositivi quando lo scegli, senza fare del cloud la fonte di verità

È una definizione più rigorosa di «offline-first». Ogni app local-first è necessariamente offline-first; un’app offline-first non è necessariamente local-first.

Quali sono le sette proprietà del software local-first?

Il saggio di Ink & Switch individua sette «ideali» che una vera app local-first dovrebbe soddisfare. Poche app li raggiungono tutti e sette, ma il quadro è utile per valutare qualsiasi candidata.

1. Niente rotelline: l’app è veloce

L’interfaccia dovrebbe rispondere alla velocità dell’hardware, non della rete. Niente icone di caricamento per le operazioni normali, come aprire un file o scrivere un paragrafo. Se devi aspettare un server, non sei local-first.

2. Il tuo lavoro non è intrappolato su un dispositivo

Dovresti poter leggere e modificare i tuoi dati su qualsiasi tuo dispositivo. Il software solo locale storicamente ha fallito qui, costringendo a sincronizzare a mano con le chiavette USB. Local-first significa che i dispositivi possono sincronizzarsi, ma il cloud è un meccanismo tra tanti, non un guardiano.

3. La rete è facoltativa

La connessione a internet dovrebbe essere un lusso, non un requisito. Prendi un aereo, vai in una baita isolata, siediti in metropolitana: l’app continua a funzionare a piena capacità. Tutto ciò che crei offline si sincronizza senza problemi quando ti riconnetti.

4. La collaborazione fluida è possibile

La collaborazione tra più utenti dovrebbe funzionare bene come nelle app cloud-first. È la proprietà più difficile da soddisfare. I Conflict-free Replicated Data Types (CRDT) e l’Operational Transformation (OT) sono le tecniche dominanti. La collaborazione in tempo reale su dati local-first crittografati è ancora un’area di ricerca attiva nel 2026.

5. Il lungo periodo: i tuoi dati sopravvivono al software

I software vanno e vengono. I tuoi dati non dovrebbero essere ostaggio di una versione specifica di un’app o di un modello di business. Le app local-first conservano i dati in formati standard (Markdown, JSON, file semplici), così restano leggibili tra cinquant’anni, anche se il software originale scompare.

6. Sicurezza e privacy di default

I tuoi dati dovrebbero essere crittografati prima di lasciare il tuo dispositivo. La crittografia end-to-end è la base, non un extra premium da vendere. Chi produce l’applicazione, e qualsiasi servizio di sincronizzazione cloud, non dovrebbe poter leggere i tuoi contenuti. Vedi la crittografia zero-knowledge spiegata per il modello tecnico che lo rende possibile.

7. Mantieni la proprietà e il controllo ultimi

Puoi esportare, eliminare o migrare i tuoi dati in qualsiasi momento. Nessun vincolo con il fornitore. Nessun «piano premium per esportare». Se lo sviluppatore alza i prezzi o chiude il servizio, continui a lavorare.

In cosa il local-first è diverso dall’offline-first?

I due termini vengono spesso usati come sinonimi. Descrivono ambiti diversi.

Proprietà	Offline-first	Local-first
Funziona senza internet	✓	✓
Dati in cache in locale	✓	✓
Il cloud è la fonte di verità	✓ (di solito)	✗
Dati utilizzabili senza l’app	✗ (di solito)	✓
Sopravvive alla chiusura dello sviluppatore	✗	✓
Crittografia nativa	✗	✓ (idealmente)
Formato dei dati standard	✗	✓

Offline-first significa «l’app gestisce con garbo l’assenza di internet». Esempi: Trello, l’app mobile di Notion, il Gmail moderno. Tengono i dati in cache in locale così puoi lavorare per poco senza connessione, ma la fonte canonica è il cloud. Se Notion chiude, la tua cache offline diventa un’istantanea congelata e inutilizzabile.

Local-first significa «la tua copia locale è la fonte di verità; il cloud è uno specchio facoltativo tra tanti». Esempi: Filarr, Obsidian, Linear, Anytype. Se lo sviluppatore chiude, hai ancora i tuoi dati in una forma utilizzabile ed esportabile.

Quali app sono davvero local-first nel 2026?

Un elenco non esaustivo di app che soddisfano la maggior parte delle sette proprietà:

Obsidian: note Markdown sul disco, ecosistema di plugin, sincronizzazione come aggiunta facoltativa a pagamento. Manca di crittografia nativa (si affida ai plugin della community).
Logseq: outliner open source, Markdown sul disco, sincronizzazione facoltativa. Forte con i grafi della conoscenza.
Anytype: app di database open source, sincronizzazione peer-to-peer crittografata end-to-end, nessun server obbligatorio.
Linear: gestione dei progetti con una cache SQLite locale come fonte di verità, sincronizzazione in background.
Standard Notes: app di note crittografate, file conservati in locale e sincronizzati crittografati.
Filarr: spazio di lavoro crittografato che riunisce file, note, vista a grafo e tela. I dati vivono crittografati sul tuo disco; la sincronizzazione cloud è facoltativa. Vedi perché il local-first conta per Filarr.
AppFlowy: alternativa a Notion open source, dati in locale, sincronizzazione facoltativa.

App spesso scambiate per local-first ma in realtà cloud-first: Notion, Google Docs, Asana, Airtable, ClickUp. Tengono i dati in cache in locale per tollerare l’assenza di rete, ma la fonte canonica è il cloud: chiude l’azienda, perdi i dati.

Notion è local-first?

No, Notion non è local-first. Notion è un’applicazione cloud-first: la copia autorevole di ogni pagina vive sui server di Notion, e le app desktop e mobili sono client che leggono e scrivono su quei server. Se il cloud di Notion non è raggiungibile, le app si degradano: le funzioni smettono di funzionare, la sincronizzazione si ferma, e il tuo unico accesso è ciò che era in cache. Chiudere il tuo account Notion significa perdere l’accesso ai dati, anche se hai esportato uno ZIP in Markdown, perché i database relazionali, le formule, i blocchi sincronizzati e gli incorporamenti non sopravvivono all’esportazione.

Figma è local-first?

No, Figma non è local-first. Figma è uno strumento di design collaborativo cloud-first: i file vivono sui server di Figma e l’applicazione è un client nel browser o incapsulato in Electron. La modifica multiutente in tempo reale di Figma è costruita sull’operational transformation tramite un server centrale, non su strutture di dati local-first senza conflitti. Figma ha un supporto offline limitato (puoi continuare a modificare per poco un file se era già aperto), ma l’architettura di fondo ha il server come riferimento.

Google Docs è local-first?

No, Google Docs non è local-first. Google Docs è cloud-first. Il documento vive nell’infrastruttura di Google; l’editor nel browser è un client leggero. La modalità offline tiene in cache i documenti recenti per modificarli senza connessione, ma il cloud resta la fonte di verità: le tue modifiche vengono unite sul server, non sul tuo dispositivo.

Quali app popolari SONO local-first?

Le seguenti vengono comunemente citate come app legittimamente local-first (ciascuna soddisfa la maggior parte delle sette proprietà di Ink & Switch):

Obsidian: file Markdown locali
Logseq: Markdown / SQLite locali
Anytype: database di oggetti locale, sincronizzazione peer-to-peer
Linear: SQLite locale come fonte di verità, sincronizzazione in background
Filarr: spazio di lavoro crittografato, dati prima di tutto sul tuo disco
AppFlowy: dati locali, sincronizzazione cloud facoltativa
Standard Notes: note crittografate, local-first con sincronizzazione facoltativa
Trilium: database di note locale, sincronizzazione su un server proprio

Perché il software local-first sta prendendo piede nel 2026?

Tre pressioni stanno convergendo.

1. La regolamentazione sulla privacy. Il GDPR, l’AI Act dell’UE e leggi simili rendono la conservazione dei dati degli utenti sui server una responsabilità crescente per i fornitori. Il local-first aggira il problema: se i dati non sono sui tuoi server, nessuna richiesta di un’autorità può costringerti a consegnarli, non puoi farli trapelare e non puoi essere multato per averli gestiti male.

2. La sfiducia verso i fornitori. Un decennio di acquisizioni, chiusure e rincari, Google Reader, i ripetuti cambi di prezzo di Evernote, il vincolo di Adobe Creative Cloud, ha insegnato agli utenti a diffidare del «i tuoi dati sui nostri server». Il local-first risponde alla domanda «cosa succede se chiudete?» con «niente, i tuoi dati sono ancora sul tuo disco».

3. La disponibilità di hardware. I dispositivi moderni hanno terabyte di spazio e processori che crittografano e decrittografano a gigabyte al secondo. Gli argomenti originali a favore del cloud-first («gli utenti non hanno abbastanza spazio su disco, i dispositivi sono troppo lenti per crittografare») non reggono più.

Nel 2019 i ricercatori di Ink & Switch sostenevano che il cloud-first avesse vinto in parte per caso: la tecnologia per rendere il local-first praticabile su larga scala non esisteva ancora. Nel 2026 esiste.

Quali sono i compromessi del software local-first?

Il local-first non è in assoluto migliore del cloud-first. I compromessi onesti:

La collaborazione multiutente in tempo reale è più difficile. La modifica simultanea alla Google Docs è il caso difficile per eccellenza. I CRDT aiutano ma aggiungono complessità, e combinare i CRDT con la crittografia end-to-end è ancora un problema di ricerca.
La configurazione iniziale è più pesante. Un’app local-first deve includere un database completo, un indicizzatore, un motore di ricerca e un motore di sincronizzazione, non solo un client leggero sopra un’API ospitata.
Il mobile è più difficile. I sistemi operativi mobili limitano l’elaborazione in background, l’accesso al file system e l’archiviazione persistente in modi che complicano il design local-first.
Gli effetti rete sono più deboli. Le app cloud-first beneficiano fin da subito di documenti condivisi, spazi di lavoro di team e pagine pubbliche; le app local-first devono aggiungere questi strati a parte.

La community local-first sta lavorando attivamente su ciascuno di questi punti. Le librerie CRDT come Automerge e Yjs stanno maturando. I framework mobili stanno allentando alcune restrizioni. La curva dei compromessi si sta spostando.

Come implementa Filarr il local-first?

Filarr è uno spazio di lavoro crittografato local-first. Le tue note, i tuoi file, i tuoi disegni e il tuo grafo della conoscenza vivono sul tuo disco, crittografati con AES-256-GCM. Non ti serve un account per usarlo. La sincronizzazione cloud è facoltativa e crittografata end-to-end: il server vede sempre e solo blob crittografati opachi che non può leggere.

In concreto, Filarr soddisfa oggi sei delle sette proprietà di Ink & Switch; la collaborazione multiutente in tempo reale è nella roadmap. Il formato dei dati è documentato ed esportabile. Anche se Filarr chiudesse domani, i tuoi file crittografati sarebbero ancora sul tuo disco, decrittografabili con la tua password: è questa la garanzia del local-first.

Scarica Filarr: gratuito, crittografato, local-first →