Per il settore pubblico
Costruiamo servizi pubblici digitali che il cittadino può utilizzare in modo facile e intuitivo. L'esperienza utente è così semplice che ogni elemento viene caricato velocemente ed è tutto facile da capire, senza alcun bisogno di guide o tutorial. Il servizio resta veloce anche quando lo usano in tanti contemporaneamente. Pulsanti, parole e percorsi sono coerenti tra il cittadino e l'operatore. Ogni aggiornamento parte da come il cittadino usa davvero il servizio, così l'esperienza migliora nel tempo.
Il report arriva due settimane prima del lancio: ottanta segnalazioni, e metà chiede un redesign che nessuno aveva messo a budget. Trattiamo WCAG 2.2 AA come una disciplina di lavoro per tutto il progetto, non come un timbro da apporre all'ultima riunione.
Bando di cinque anni, scope rigido, niente margine per far evolvere l'architettura durante il contratto. Il fornitore che vince promette cose che poi non consegna, e i concorrenti seri non partecipano nemmeno alla gara. In entrambi i casi a pagare è il cittadino.
SPID, CIE, eIDAS, schemi regionali. Ogni integrazione finisce in un flusso a parte, con la sua sessione, il suo registro, la sua interfaccia. Chi prova ad accedere incontra una porta diversa ogni volta, e dopo il primo tentativo l'esperienza non si recupera più.
Il contratto finisce, il codice resta su una piattaforma proprietaria, la gara successiva ricomincia da zero. Il denaro pubblico paga due volte lo stesso servizio.
Testiamo con tecnologie assistive mentre il codice si scrive, e non a progetto chiuso. La dichiarazione di accessibilità la generiamo dal codice in produzione e la aggiorniamo a ogni rilascio, così resta allineata a quello che il cittadino vede davvero sullo schermo.
Hosting, database, archiviazione, code, CDN: configuriamo ogni componente in regione UE, con il fornitore vincolato per contratto. Il flusso dei dati lo descriviamo in un diagramma che il responsabile della protezione dei dati firma senza riserve.
Un unico livello di autenticazione copre la carta d'identità elettronica, le identità bancarie, e i provider eIDAS transfrontalieri. Chi accede trova lo stesso flusso con qualunque provider, e l'ente legge in un solo registro chi ha fatto cosa e con quale identità.
Italiano, lingue regionali, lingue minoritarie riconosciute, ciascuna nel routing dell'URL, con hreflang corretto, plurali ben gestiti, e dichiarazione di accessibilità localizzata per lingua. Le traduzioni le lavoriamo dentro la fase di progettazione, e non come una tabella di stringhe che si compila la settimana prima del lancio.
Chi ha cambiato cosa, quando, da quale indirizzo, con quale motivazione. Il registro è interrogabile, esportabile, firmato. Il giorno della verifica la risposta è già pronta.
Codice sorgente nei vostri repository, infrastruttura sui vostri account, documentazione generata dal codice, design system consegnato in un pacchetto versionato. La gara successiva parte con materiali in mano, e non da un foglio bianco.
Ogni scelta tecnica si appoggia a un dato di fatto. I servizi pubblici stanno online per anni, i requisiti dei cittadini crescono nel tempo, e il prossimo team a leggere il codice potrebbe non essere il nostro. Scegliamo lo stack pensando a quel secondo momento, quando il contratto è finito e c'è qualcun altro ad aprire il progetto.
L'area cittadino e il pannello degli operatori stanno dentro lo stesso progetto Next.js. Il servizio si indicizza sui motori di ricerca, si apre veloce al primo accesso, e chi pubblica i contenuti lavora dallo stesso posto in cui si istruiscono le pratiche. Un solo repository, un solo rilascio, e la distinzione fra "la pagina che vede il cittadino" e "il sistema che istruisce la sua richiesta" smette di costare coordinamento fra dipartimenti.
I dati del cittadino restano separati a livello di database, e non solo dentro il codice dell'applicazione. È il punto su cui si gioca ogni verifica di un servizio pubblico, perché la domanda è sempre la stessa: come si garantisce davvero la separazione fra dipartimenti, enti, o gruppi sensibili. Con un Postgres gestito e una regola che filtra l'accesso riga per riga, la risposta sta in una schermata di codice, e finisce direttamente nella documentazione tecnica del servizio. Lo stesso database gestisce account, allegati, e aggiornamenti in tempo reale, in regione UE per contratto.
Mettiamo SPID, CIE, il nodo eIDAS, e gli schemi regionali dentro un solo livello di sessione. Chi accede trova lo stesso flusso qualunque provider scelga. Il registro delle azioni traccia il provider usato per ciascun evento, e quando la verifica di accessibilità chiede come una persona che usa un lettore di schermo arriva al modulo di richiesta, la risposta è lo stesso flusso che vale per tutti, senza scorciatoie pensate solo per chi vede.
I documenti che richiedono firma elettronica qualificata passano da un provider compatibile con eIDAS. Il PDF firmato resta accanto al record della pratica, con i tempi di conservazione previsti dalla normativa di settore. La ricevuta che riceve il cittadino arriva dallo stesso modello che usa l'operatore interno, e per questo le due versioni non si allontanano nel tempo.
Il costo dell'infrastruttura non sale a sorpresa al crescere del traffico. Per la protezione dagli abusi usiamo una cache distribuita gestita, vicina geograficamente alle persone che fanno richiesta, e senza bisogno di un server dedicato. Gli allegati restano in uno storage di oggetti in regione UE, senza le sorprese che la voce "trasferimento dati in uscita" porta con sé altrove. Tutto il codice viene verificato in compilazione da TypeScript, un beneficio poco scenografico ma decisivo: quando il contratto finisce e un altro team apre il progetto, gli errori vengono fuori prima del rilascio, e la persona che entra si orienta senza visita guidata.
Sì. Abbiamo lavorato dentro bandi a scope fisso, accordi quadro, e ordini diretti su Mercato Elettronico. Scriviamo il capitolato tecnico nel formato che chiede l'ufficio gare, e tagliamo lo scope perché il contratto porti una definizione di fatto verificabile.
WCAG 2.2 AA è la base minima da cui partire. I test con tecnologie assistive li facciamo durante lo sviluppo, e non a fine progetto. La dichiarazione di accessibilità la generiamo dal codice del servizio, e per questo non si allontana mai dalla realtà. La Legge Stanca aggiornata e l'European Accessibility Act 2025 si coprono con la stessa disciplina.
Sì. Hosting, database, archiviazione di file, code e CDN li configuriamo tutti in regioni UE con fornitori vincolati per contratto. Il flusso dei dati lo documentiamo perché il responsabile della protezione dei dati lo firmi senza obiezioni.
Un passaggio di consegne che un altro team può davvero raccogliere. Codice sorgente nei vostri repository, infrastruttura sui vostri account, documentazione generata dal codice, design system in un pacchetto versionato. La gara successiva parte con materiali in mano, e non da un foglio bianco.
Sì. Il routing, lo hreflang, i plurali ben gestiti, e le dichiarazioni di accessibilità per ogni lingua fanno parte del lavoro di sviluppo, e non sono un'aggiunta finale. Abbiamo già rilasciato servizi multilingua dal primo deploy, e lo stesso schema vale per le lingue tutelate dalla normativa italiana.
Una chiamata per inquadrare il progetto, e un piano concreto nella prima risposta. Rispondiamo ai bandi entro la scadenza indicata.
Founder SaaS, dal pre-seed alla Series A
Founder fintech che sviluppano neobank, wallet, lending, pagamenti
Aziende manifatturiere mid-market che rilasciano cruscotti operativi
Founder che sviluppano prodotti cloud per consumer e utility app