infrastruttura · provisioning
Sistema demo dei gestionali
Il prospect non deve ricevere un gestionale vuoto. Riceve il suo, già pieno, con il suo marchio dentro.
Questo ha un accesso riservato e vieta di farsi incorniciare: è la difesa che impedisce a chiunque di mettere un modulo di login dentro una pagina non sua.
cat ./contesto.md
Prodotto Fymera · 2026
./ruolo --nostro
Architettura e sviluppo interni
Prima e dopo
com'era
La prova di un gestionale di solito fallisce prima di cominciare: chi si registra trova un sistema vuoto e dovrebbe creare azienda, categorie, prodotti, immagini, listini e utenti prima di capire se gli serve. Quasi nessuno arriva in fondo.
cos'abbiamo costruito
Un sistema che prepara la demo al posto suo: ambiente già popolato con catalogo, prodotti, varianti, materiali, utenti, documenti e branding del prospect. Si entra e il gestionale funziona già.
$ ls ./componenti
Com'è fatto
-
01
Provisioning automatico
Ogni demo nasce con schema di database dedicato, control plane per crearla e cancellarla, e scadenza.
-
02
Isolamento reale
Nessun ripiego sul database principale: i dati di una demo non toccano quelli di un'altra né quelli di produzione.
-
03
Popolata e personalizzata
Catalogo plausibile e marchio del prospect: si valuta il prodotto, non la propria pazienza nel caricare dati.
$ ./risultati --dopo
Com'è andata
[ok] La valutazione comincia dal prodotto funzionante, non dal caricamento dati
[ok] Ogni demo isolata, con scadenza e cancellazione previste
[ok] È la caratteristica che distingue la famiglia di gestionali Fymera
// servizi coinvolti
$ ls ./altri-casi
Hai un progetto simile?
Trenta minuti in video per capire se ha senso farlo, e quanto costa davvero. Se non siamo noi quelli giusti, te lo diciamo.
