Servizi che i cittadini riescono davvero a usare
La maggior parte dei servizi digitali pubblici viene rifatta ogni sei anni e arriva online ancora inaccessibile. Noi li mettiamo online una volta sola, fatti bene: WCAG 2.2 AA dal primo commit, audit log dal primo giorno, documentazione pronta per l'ente che verifica.
I problemi che sentiamo più spesso
L'audit di accessibilità arriva alla fine, quando rimediare costa dieci volte tanto
Due settimane prima del lancio compare il report, conta 80 segnalazioni e metà richiede un redesign che nessuno ha messo a budget. WCAG 2.2 AA funziona come disciplina di lavoro, non come timbro finale.
Un servizio pensato per Internet Explorer nel 2014 che oggi si rompe sul telefono
Il capitolato chiedeva il supporto a IE11, il contratto è del 2019, il modulo di richiesta non apre su un Android di quattro anni fa. La baseline sbagliata blocca tutto in partenza.
Appalti che escludono lo stack moderno
Bando quinquennale, scope rigido, nessuno spazio perché l'architettura evolva. Il fornitore vince promettendo cose che poi non riesce a consegnare, i concorrenti seri stanno fuori. In entrambi i casi paga il cittadino.
Identità digitale trattata come una casella da spuntare
SPID, CIE, eIDAS, schemi regionali: ognuno integrato con il proprio flusso, la propria sessione, il proprio audit. L'esperienza per chi entra nel servizio non si riprende più. L'identità è la porta d'ingresso, merita la stessa cura del resto del palazzo.
Multilingua aggiunto alla fine, fatto male
Il servizio nasce in italiano, le lingue regionali e minoritarie passano da una traduzione automatica, la dichiarazione di accessibilità è nella lingua sbagliata. Il plurale delle lingue è una scelta di architettura, non una tabella di stringhe da tappare a fine progetto.
Documentazione di conformità scritta separata dal codice
L'informativa privacy dice una cosa, il registro dei trattamenti ne dice un'altra, la dichiarazione di accessibilità è stata generata sei mesi fa da un template. Il giorno dell'ispezione tre documenti non concordano.
Lock-in del fornitore mascherato da "servizio gestito"
Finisce il contratto, il codice vive su una piattaforma proprietaria e la gara successiva riparte da zero. Il denaro pubblico paga due volte lo stesso servizio.
Cosa consegniamo in questo verticale
WCAG 2.2 AA dal primo commit
Accessibilità pronta per l'audit, non uno sprint di remediation. La dichiarazione di accessibilità nasce dal codice vero, aggiornata a ogni rilascio.
Dati ospitati in Europa per architettura
Hosting, database, storage e code: tutto in regioni UE, vincolato per contratto. Niente fallback negli Stati Uniti.
Identità digitale in una sessione sola
SPID, CIE, nodo eIDAS, schemi regionali integrati in un unico livello di autenticazione. Stessa esperienza per chiunque entri, stessa tracciabilità per chi audita.
Multilingua come scelta progettuale
Italiano, lingue regionali, lingue minoritarie ufficiali. Routing nell'URL, hreflang corretto, copy con plurali coerenti, dichiarazione di accessibilità localizzata.
Audit log su ogni azione privilegiata
Chi ha cambiato cosa, quando, da quale IP e con quale motivazione. Esportabile, interrogabile, firmato.
Flusso documentale con firma qualificata eIDAS
Generazione PDF, firma elettronica qualificata conforme eIDAS, conservazione a norma con i tempi di retention che il tuo servizio richiede per legge.
Open source dove conta
Stack standard che il prossimo team riesce a leggere. Nessuna clausola di lock-in, nessuna licenza per utente sul codebase, nessuna sorpresa al rinnovo.
Performance scritta nel contratto
Obiettivi Core Web Vitals nel capitolato, verificati sotto carico, riportati a ogni rilascio. INP sotto i 200 ms, LCP sotto i 2,5 secondi, misurati sui dispositivi reali dei cittadini.
API per l'interoperabilità (compatibili PDND)
Specifica OpenAPI, versionata, rate-limited, documentata. Le altre amministrazioni si integrano senza sei mesi di tavoli tecnici.
Documentazione pronta per il bando
Relazione tecnica, sicurezza, dichiarazione di accessibilità, registro dei trattamenti, piano di conservazione. Generati dal codice, non da un modello.
Front-end di servizio per il cittadino
Domande, stato delle pratiche, caricamento documenti, ricevute. Funziona da telefono, nelle lingue supportate, anche senza account se la normativa lo permette.
Passaggio di consegne che non lascia il prossimo team a piedi
Design system, documentazione, runbook. La gara successiva parte con materiali pronti, non da un foglio bianco.
Uno stack che regge un contratto quinquennale
Ogni scelta tecnica qui sotto nasce dal fatto che il ciclo di vita nel settore pubblico è lungo, i requisiti per il cittadino crescono nel tempo e il prossimo team che metterà mano al codice potrebbe non essere il nostro. Scegliamo tecnologia che regge in quel secondo momento, quando il contratto è finito e c'è qualcun altro a leggere il codice.
Front-end per i cittadini e back office per gli operatori vivono in un unico codebase, basato su Next.js App Router. Il servizio pubblico si indicizza correttamente, si apre veloce al primo click e chi gestisce i contenuti lavora dallo stesso posto in cui si istruiscono le pratiche. Un solo repository, un solo deploy e la distinzione fra "la pagina che vede il cittadino" e "il sistema che ne istruisce la richiesta" smette di essere un costo di coordinamento.
I dati del cittadino restano separati a livello di database, non nel codice applicativo, e questo è il punto: ogni verifica di un servizio pubblico finisce per chiedere la stessa cosa, ossia come si garantisce la separazione fra dipartimenti, enti o gruppi sensibili. Con Supabase Postgres e row-level security la risposta sta in una schermata di codice e finisce nella documentazione tecnica che accompagna il servizio. Lo stesso database gestisce anche account, allegati e aggiornamenti in tempo reale, ospitato in regione UE per contratto.
L'autenticazione mette SPID, CIE, nodo eIDAS e schemi regionali su un unico livello di sessione. Il cittadino fa la stessa esperienza con la carta di identità elettronica, con un fornitore di identità bancaria o con un eIDAS transfrontaliero, mentre l'audit log registra quale provider è stato usato per ciascuna azione. Quando l'audit di accessibilità chiede come uno screen reader arriva alla pratica, la risposta è lo stesso flusso, senza scorciatoie pensate solo per chi vede.
I documenti che richiedono firma elettronica qualificata passano da un servizio eIDAS-compliant, con il PDF firmato conservato accanto al record della pratica e con la retention prevista per il tuo servizio. La ricevuta che il cittadino riceve nasce dallo stesso modello che usa l'operatore interno e le due versioni non divergono mai.
Un'infrastruttura che non si gonfia di costi al crescere del traffico: Upstash Redis at the edge gestisce rate limit e protezione anti-abuso senza tirare su un server, Cloudflare R2 conserva gli allegati in regione UE senza costi di egress imprevedibili e tutto lo stack è type-checked con TypeScript dall'inizio alla fine. Il vantaggio è poco scenografico ma decisivo: quando il contratto finisce e un altro team apre il codice, gli errori escono in build invece che in produzione e la persona che apre il progetto si orienta senza una visita guidata.
Domande che fanno i founder
Lavorate con MEPA, Consip e gli appalti pubblici?
Sì. Abbiamo lavorato dentro bandi a scope fisso, accordi quadro e ordini diretti su Mercato Elettronico. Scriviamo il capitolato tecnico nel formato richiesto dall'ufficio gare e tagliamo lo scope in modo che il contratto abbia un perimetro verificabile.
WCAG 2.2 AA, Legge Stanca, European Accessibility Act: come li gestite?
WCAG 2.2 AA è il pavimento, non il soffitto. Testiamo con tecnologie assistive durante la build, non a fine progetto, e la dichiarazione di accessibilità nasce dal codebase per non divergere mai dalla realtà. La Legge Stanca aggiornata e l'European Accessibility Act 2025 si coprono con la stessa disciplina.
I dati restano in Europa?
Sì. Hosting, database, storage di file, code e CDN si configurano tutti in regioni UE con fornitori vincolati per contratto. Documentiamo il flusso dei dati in modo che il responsabile della protezione dei dati possa firmarlo senza dubbi.
Come integrate SPID, CIE ed eIDAS?
Un solo livello di sessione li copre tutti, con lo stesso audit log e la stessa esperienza per il cittadino, indipendentemente dal provider scelto. L'integrazione è già un percorso conosciuto, non una sorpresa a metà progetto.
Cosa succede a fine contratto?
Un passaggio di consegne che un altro team riesce a riprendere in mano. Codice sorgente nei tuoi repository, infrastruttura sui tuoi account, documentazione scritta dal codice e non da un modello, design system in un pacchetto versionato. La gara successiva parte da materiali pronti, non da un foglio bianco.
Supportate le lingue regionali e minoritarie?
Sì. Routing, hreflang, copy con plurali coerenti e dichiarazioni di accessibilità per ciascuna lingua fanno parte della build, non sono un'aggiunta finale. Abbiamo messo online servizi multilingua dal primo commit e lo stesso schema vale per le lingue tutelate dalla normativa italiana.
Fate migrazione di sistemi legacy?
Sì. La maggior parte dei servizi pubblici su cui lavoriamo sostituisce qualcosa che esiste già. Trattiamo gli utenti attuali come baseline, non come foglio bianco: gli identificativi si portano dietro l'utente, lo storico delle pratiche resta consultabile, il nuovo servizio parte con parità di funzionalità o con un piano di migrazione documentato.
Come fatturate verso la pubblica amministrazione?
Fatturazione elettronica via SDI, con il codice destinatario o la PEC dell'ente. La nostra struttura amministrativa è abituata agli ordini di acquisto, ai SAL e alla tracciabilità dei pagamenti previsti dal Codice degli Appalti.
Raccontaci il servizio
Una call di scoping, un piano concreto nella prima risposta, niente recite da agenzia. Rispondiamo ai bandi entro la scadenza indicata.