Evoluzione di un prodotto iniziale in piattaforma SaaS multi-modulo con licenze, add-on, permessi, API, test e release.
Cosa e stato studiato
Sono stati analizzati flussi ricorrenti di team e clienti: task, ore, documenti, richieste di supporto, booking e accessi. Il punto critico era evitare un prodotto monolitico difficile da evolvere, mantenendo pero una base coerente per dati, permessi e viste operative. Il progetto non poteva limitarsi a sommare schermate: doveva definire un modello comune per identita, autorizzazioni, moduli attivabili, storico e report, lasciando ai singoli servizi abbastanza autonomia da crescere nel tempo.
Cosa e stato fatto
La piattaforma e stata modellata come sistema multi-modulo, con servizi attivabili, API REST, gestione utenti, licenze e add-on. I moduli principali condividono logiche comuni, ma restano separati abbastanza da poter essere evoluti senza rompere tutto il prodotto. Task, documenti, time tracking, ticket e supporto non sono stati trattati come applicazioni isolate: sono diventati domini collegati da permessi, tenant, stati e regole di visibilita.
Come e stato fatto
La realizzazione ha usato PHP custom e database relazionale, integrando componenti specifici come companion desktop, IMAP e funzioni AI dove utili. Il lavoro e stato accompagnato da smoke test, release progressive e vincoli pubblici su cosa mostrare e cosa tenere fuori dal racconto commerciale. Le scelte architetturali sono state orientate a rendere ogni evoluzione verificabile: moduli accendibili, dati tracciati, API utilizzabili da superfici diverse e test mirati sui flussi piu fragili.
Architettura e tecnologie
Come lo stack e stato usato nel progetto
Architettura modulare e dominio condiviso
ShareHub e stato organizzato come piattaforma modulare: task, documenti, ore, supporto e servizi aggiuntivi condividono identita, permessi, tenant e regole di attivazione. Questa architettura e stata sfruttata per evitare che ogni modulo diventasse un prodotto separato; il vantaggio e che un cliente puo usare solo cio che gli serve, mentre la piattaforma mantiene un modello unico per utenti, ruoli, storico e report.
API REST e separazione delle superfici
Le API REST sono state usate per separare la logica operativa dalle interfacce che la consumano. La web app, il companion desktop e le integrazioni possono leggere o aggiornare informazioni senza duplicare regole di business. In pratica, la scelta architetturale serve a far evolvere dashboard, automazioni e client esterni mantenendo il backend come sorgente autorevole di stati, permessi e validazioni.
Database relazionale, permessi e licenze
MySQL/MariaDB e stato mantenuto come base dati relazionale per modellare entita con collegamenti forti: utenti, tenant, moduli, licenze, task, documenti, ticket, ore e configurazioni. La struttura relazionale e stata sfruttata per rendere interrogabili i rapporti tra lavoro e governance: quali moduli sono attivi, chi puo vedere cosa, quali attivita appartengono a un cliente e quali dati entrano nei report.
Companion desktop e sincronizzazione operativa
Il companion Electron ha un ruolo specifico: ridurre l'attrito del time tracking e collegare il lavoro locale al contesto ShareHub. L'architettura desktop-backend e stata sfruttata per raccogliere segnali operativi vicino al punto in cui il lavoro avviene, ma senza spostare la responsabilita del dato fuori dalla piattaforma. Il backend resta il punto di verita, il client desktop diventa una superficie di acquisizione e sincronizzazione.
AI, IMAP e automazioni dentro regole esistenti
IMAP e funzioni AI non sono state pensate come elementi scenici, ma come componenti inseriti dentro flussi governati: lettura o classificazione di comunicazioni, supporto alla sintesi, aggancio a ticket o documenti. L'architettura modulare consente di usare OpenAI dove porta valore senza trasformare il prodotto in una chat generica: ogni output resta collegato a un'entita, a un permesso e a un'azione verificabile.
Test, release e controllo regressioni
La natura multi-modulo impone verifiche trasversali: una modifica a permessi, licenze o stati puo impattare piu aree. Per questo sono stati usati smoke test e release progressive sui flussi critici, con attenzione a login, accessi, attivazione servizi, API e report. L'obiettivo tecnico e ridurre regressioni invisibili, cioe problemi che non rompono una pagina ma alterano il comportamento operativo del SaaS.
Pattern implementativi
Dettagli tecnici che hanno guidato le scelte
Boundary modulari, service layer e policy di autorizzazione
La piattaforma e stata ragionata per boundary funzionali: ogni modulo espone capacita specifiche, ma passa da un service layer comune per identita, permessi, tenant e licenze. Questo consente di evitare controller pieni di logica applicativa e di mantenere policy di autorizzazione riusabili. In termini architetturali, il modulo non decide da solo chi puo fare cosa: interroga una governance centrale e applica regole coerenti su viste, API e azioni operative.
Contratti API, DTO e riduzione dell'accoppiamento
Le API REST diventano un contratto tra backend e superfici applicative. Il companion desktop, eventuali dashboard e integrazioni esterne non devono conoscere la struttura interna delle tabelle: consumano payload stabili, serializzati in modo controllato. Questo approccio riduce l'accoppiamento, permette refactoring interni e rende piu chiaro dove versionare o proteggere un cambiamento di dominio.
State management, audit trail e consistenza operativa
Task, ticket, ore e documenti sono trattati come oggetti con stati e transizioni, non come record passivi. Lo storico operativo serve da audit trail: chi ha creato, modificato, assegnato, allegato o chiuso un elemento. Questo e importante per gestire accountability, ricostruzione delle decisioni e consistenza cross-modulo, soprattutto quando un'azione su un ticket genera lavoro interno o quando un timer alimenta report e consuntivi.
AI assistita con fallback deterministico
L'uso di AI e IMAP viene incapsulato dentro flussi applicativi deterministici: classificazione, sintesi o assistenza non sostituiscono lo stato ufficiale del sistema. Il pattern corretto e trattare l'output AI come suggerimento o arricchimento, con fallback manuale, logica di validazione e permessi gia esistenti. Questo evita che una funzione generativa diventi una scorciatoia fuori governance.
Risultati e apprendimenti
Prodotto online, versione pubblica, moduli reali, ampia cronologia evolutiva e test interni.
- un SaaS operativo richiede regole di prodotto prima delle singole feature
- i moduli funzionano meglio se condividono identita, permessi e tracciabilita
- le integrazioni AI vanno inserite dentro controlli operativi esistenti