Unitiva

Per anni, il Server-Side Rendering in Angular ha avuto un problema "nascosto".
Le pagine arrivavano velocemente dal server, ma il passaggio all'interattività client-side era tutt'altro che invisibile.

Flicker, layout shift, interfacce che saltavano durante il caricamento della SPA... vi suona familiare?

Con le versioni 17 e 18, l'approccio di Angular è cambiato radicalmente. L'obiettivo non è più solo ottimizzare la SEO, ma creare applicazioni web che risultino immediatamente interattive e fluide per l'utente.

Qui il link all'articolo di Alessandro Ieri:

Angular SSR e Hydration: verso un web istantaneo Client-Side Hydration, Transfer State, Event Replay: come Angular ha risolto i problemi di caricamento delle SPA e reso l'interattività immediata.

C'è un vantaggio di Odoo che quasi nessuno cita quando si parla di equity: il capitale sociale smette di vivere sparso ovunque.

Quote nei file del notaio. Movimenti di capitale in contabilità. Accordi di vesting tra email e PDF. Anagrafica soci aggiornata solo all'occorrenza. Nelle aziende in crescita questa frammentazione è la norma, e si fa sentire proprio nel momento peggiore: quando si avvicina un round e la documentazione serve in tempi stretti.

Portare questi dati nell'ERP cambia le regole del gioco. L'anagrafica dei soci dialoga con i movimenti contabili, e i documenti legali trovano finalmente una casa strutturata nello stesso sistema.

E la parte contabile è solida davvero. Quando un investitore sottoscrive un aumento di capitale, Odoo registra tutto in partita doppia, aggiorna i conti di classe 1 in tempo reale, garantisce la quadratura automatica. Persino la distinzione tra versamento in conto futuro aumento e iscrizione a capitale dopo delibera notarile è gestita con la precisione che chi fa queste scritture si aspetta.

Su questa base solida un partner affidabile costruisce il resto: cap table strutturato, vesting schedule, simulazioni di exit. Layer progettati su misura, che poggiano su dati che nell'ERP esistono già e che non vanno ricreati da zero ogni volta che serve una risposta.

Per founder e CFO il messaggio è semplice: una sola fonte di verità su cui far girare le decisioni, dalla contabilità ordinaria fino al prossimo round.

Ne parliamo per esteso nel nostro articolo 👉

Gestire il Capitale Sociale con Odoo: cosa funziona davvero e cosa richiede sviluppo custom Per founder e CFO che vogliono portare l'equity management nell'ERP in maniera corretta

Due persone, lo stesso cliente, la stessa sessione di discovery.
Due documenti di analisi diversi.
Non perché una sbagli e l'altra no. Ma perché l'analisi porta sempre con sé chi l'ha scritta: domande poste in ordine diverso, dettagli che a qualcuno sembrano centrali e ad altri marginali, una struttura che cambia ogni volta.

È il problema che abbiamo risolto con Unitiva Discovery, la web app che usiamo internamente durante la discovery. Guida il PM lungo lo stesso percorso di domande, attinge a una knowledge base strutturata sui moduli di Odoo e a fine sessione genera da sola il documento di analisi. Certo, il documento va comunque rivisto da chi conosce il cliente. Ma il grosso del lavoro è già fatto.

Il risultato non è solo più veloce. È più uniforme. La qualità del documento smette di dipendere da chi conduce la sessione quel giorno e il PM si concentra su ciò che conta davvero: le eccezioni, le personalizzazioni, il valore che il cliente cerca.

Per noi però la parte interessante è un'altra.
Questo strumento non l'ha costruito un team di sviluppo. L'ha costruito una persona sola, con un metodo basato sugli agenti AI: 240 commit, senza scrivere codice riga per riga.

Se nel tuo lavoro c'è un'attività dove il risultato dipende troppo da chi la esegue, con ogni probabilità si può trasformare in uno strumento.
Abbiamo raccontato come, nel nuovo case study:

Unitiva Discovery: come abbiamo costruito il nostro tool interno con Claude Code Un PM, nessun team di sviluppo, 240 commit. Il metodo che ha trasformato un agente AI in un collaboratore di sviluppo affidabile

Se nel tuo gruppo convivono più società nello stesso database, conosci bene quel momento di fine mese: qualcuno controlla se una fattura infragruppo è stata registrata da entrambe le parti. Con gli stessi numeri. Nello stesso periodo.

È uno di quei lavori che non aggiunge valore ma porta via tempo e attenzione. E che, prima o poi, genera la riga che non quadra.

Qui c'è una buona notizia per chi sta valutando l'adozione di Odoo.

Le 𝐈𝐧𝐭𝐞𝐫-𝐂𝐨𝐦𝐩𝐚𝐧𝐲 𝐓𝐫𝐚𝐧𝐬𝐚𝐜𝐭𝐢𝐨𝐧𝐬 generano in automatico i documenti speculari tra le entità: un ordine di acquisto in Azienda B crea l'ordine di vendita in Azienda A. E oggi anche il ciclo di fatturazione si chiude da solo: la conferma di una fattura in una società genera la contropartita nell'altra, mantenendo i due registri contabili allineati senza intervento manuale.

Meno doppio data-entry. Meno telefonate tra uffici per allineare i numeri. Meno riconciliazioni a fine mese.

Una precisazione onesta, perché le aspettative contano: "𝐚𝐮𝐭𝐨𝐦𝐚𝐭𝐢𝐜𝐨" 𝐧𝐨𝐧 𝐯𝐮𝐨𝐥 𝐝𝐢𝐫𝐞 "𝐬𝐞𝐧𝐳𝐚 𝐜𝐨𝐧𝐟𝐢𝐠𝐮𝐫𝐚𝐳𝐢𝐨𝐧𝐞". Posizioni fiscali, localizzazioni coerenti, mappatura dei prodotti condivisi e gestione delle triangolazioni IVA vanno impostate a monte, sui requisiti reali dell'azienda e sulla normativa italiana. Quando la base è fatta bene il guadagno in tempo ed errori eliminati è concreto e misurabile.

Matteo Amati ci racconta come funziona il ciclo intercompany in Odoo: cosa si automatizza, cosa va configurato e cosa non si improvvisa.

Link all'articolo 👇

Il ciclo inter-company in Odoo: cosa funziona davvero, cosa va configurato e cosa non si improvvisa Automazione reale, aspettative corrette.

Componente → API REST → controller → ORM → database.

Ogni salto costa: latenza, codice da mantenere, punti di failure. Con i React Server Components quel salto non esiste più. Il componente interroga il database direttamente e al client arriva solo markup già renderizzato.

Per un SaaS con decine di endpoint CRUD significa meno superficie di attacco, meno test, meno debito architetturale. Ma sarebbe disonesto fermarsi qui: le parti interattive restano client-side, il caching distribuito resta difficile, il debugging cambia modello mentale.

Nel nuovo articolo del magazine mettiamo in fila cosa cambia davvero per chi costruisce SaaS nel 2026: multi-tenancy, streaming con Suspense, costi di infrastruttura e i criteri per decidere se e come migrare.

Link 👇

React Server Components nel 2026: cosa cambia davvero per chi costruisce SaaS I React Server Components non sono solo un'ottimizzazione tecnica. Per chi sviluppa prodotti SaaS, cambiano le regole del gioco su costi, architettura e velocità di delivery.

👉 La tua azienda è pronta per il 2 agosto 2026?

Da quella data, gli obblighi dell'AI Act per i sistemi ad alto rischio diventano pienamente operativi. Non è lontano.

Stefania Scolamiero ha approfondito l'argomento sul nostro magazine: cosa prevede davvero il Regolamento, chi è coinvolto, cosa fare adesso (senza gergo giuridico).

Se avete voglia di saperne di più: https://unitiva.it/news/ai-act-e-governance-leuropa-ridisegna-le-regole-dellintelligenza-artificiale

Cos'è LoraDevice? È il passo successivo nel percorso di LoraBot: abbiamo liberato la nostra AI dallo schermo e le abbiamo dato una presenza fisica, vocale, immediata. Niente più frizioni, basta pronunciare il suo nome.

Dietro c'è un progetto multidisciplinare sviluppato insieme ai ricercatori della Sapienza Università di Roma, che unisce product design, AI, Odoo e un approccio serio all'accessibilità e alla privacy.

Tutti i dettagli nell'articolo di Paolo De Luise: https://unitiva.it/case-study/loradevice-quando-lintelligenza-artificiale-prende-forma-fisica

𝐒𝐜𝐞𝐠𝐥𝐢𝐞𝐫𝐞 𝐮𝐧 𝐄𝐑𝐏 𝐩𝐞𝐫 𝐢𝐥 𝐟𝐨𝐨𝐝 𝐞̀ 𝐮𝐧𝐚 𝐝𝐞𝐥𝐥𝐞 𝐝𝐞𝐜𝐢𝐬𝐢𝐨𝐧𝐢 𝐩𝐢𝐮̀ 𝐜𝐨𝐦𝐩𝐥𝐞𝐬𝐬𝐞 𝐜𝐡𝐞 𝐮𝐧𝐚 𝐝𝐢𝐫𝐞𝐳𝐢𝐨𝐧𝐞 𝐚𝐳𝐢𝐞𝐧𝐝𝐚𝐥𝐞 𝐬𝐢 𝐭𝐫𝐨𝐯𝐚 𝐚𝐝 𝐚𝐟𝐟𝐫𝐨𝐧𝐭𝐚𝐫𝐞.

Non perché i software manchino.
Perché mancano spesso le domande giuste da fare prima di firmare.

𝐓𝐫𝐚𝐜𝐜𝐢𝐚𝐛𝐢𝐥𝐢𝐭𝐚̀ bidirezionale reale (non "sì, gestiamo i lotti").
𝐃𝐢𝐬𝐭𝐢𝐧𝐭𝐚 𝐛𝐚𝐬𝐞 che sa stare dietro alla variabilità della materia prima.
𝐂𝐨𝐧𝐭𝐫𝐨𝐥𝐥𝐨 𝐪𝐮𝐚𝐥𝐢𝐭𝐚̀ 𝐢𝐧𝐭𝐞𝐠𝐫𝐚𝐭𝐨, non un Excel parallelo.
𝐋𝐨𝐠𝐢𝐜𝐡𝐞 𝐅𝐄𝐅𝐎 con shelf-life residua differenziata per cliente.
API aperte per parlare con le macchine in produzione.
EDI con la GDO, senza workaround manuali.
Un partner che conosce BRC e IFS (non genericamente "la manifattura").

Abbiamo raccolto i 7 errori più comuni che vediamo nelle implementazioni ERP in ambito alimentare, non da benchmark teorici, ma da progetti reali (guarda la sezione dei casi di studio di unitiva.it per leggerne qualcuno)

https://unitiva.it/technology/i-7-errori-fatali-nella-scelta-di-un-erp-per-il-settore-alimentare-e-come-evitarli

𝐈𝐧𝐭𝐞𝐠𝐫𝐚𝐫𝐞 Odoo con un sistema esterno è una delle operazioni più delicate che un team di sviluppo possa affrontare. Non perché sia tecnicamente impossibile. Ma perché i problemi più seri non fanno rumore.

I log dicono tutto ok. I processi girano. Eppure qualcosa non torna, e lo scopri settimane dopo, quando il danno è già fatto.

Abbiamo visto questo scenario ripetersi su progetti di ogni dimensione: 𝐖𝐌𝐒, 𝐦𝐚𝐫𝐤𝐞𝐭𝐩𝐥𝐚𝐜𝐞, 𝐏𝐈𝐌, 𝐄𝐑𝐏 𝐥𝐞𝐠𝐚𝐜𝐲.
Ogni volta, gli stessi pattern ricorrenti. Ogni volta, le stesse assunzioni implicite che nessuno aveva reso esplicite.

Abbiamo fatto un'analisi completa, con le soluzioni architetturali per ciascuno scenario: https://unitiva.it/news/sincronizzare-linvendibile-casi-limite-di-integrazione-tra-odoo-e-piattaforme-proprietarie