Caso di successo: eclipseando.com, un sito e un backend di ecommerce realizzati da zero in 19 giorni

Il 12 agosto 2026 ci fu un'eclissi totale di sole sulla Spagna. Il 24 luglio eclipseando.com non esisteva: né dominio, né design, né una riga di codice. Diciannove giorni dopo il sito era online con una pagina per ogni comune della Spagna, un negozio che incassava con Stripe e una catena logistica che inviava ordini a quattro fornitori diversi. Lo raccontiamo qui perché è il progetto che mostra meglio come lavoriamo quando l'incarico è «un sito e un backend da zero», e perché ogni componente è in produzione e si può visitare.

L'incarico: un sito con data di scadenza

Il progetto era nostro, non di un cliente, e questo lo rende un esempio più onesto: non c'era un budget da allungare né una scadenza negoziabile. La data la decideva il cielo. I requisiti nascevano da una ricerca preliminare ed erano concreti: rispondere a «a che ora e quanto si vede dal mio paese?» per qualsiasi comune della Spagna, vendere occhiali omologati e souvenir personalizzati per comune, e farlo anche in catalano, inglese, tedesco, francese, italiano e portoghese, perché parte del pubblico veniva dall'estero.

Abbiamo scartato Shopify e WooCommerce prima di iniziare. Non per il prezzo, ma perché la parte difficile del progetto non era il negozio: erano le 8.132 pagine calcolate, la mappa, la previsione delle nuvole e alcune integrazioni logistiche che nessuna piattaforma offre di serie. Quando il valore sta in ciò che non viene di serie, la piattaforma intralcia più di quanto aiuti. Lo stesso criterio lo applichiamo quando un cliente ci chiede se realizzare il suo sito su Odoo Website o a parte.

Cosa è stato costruito, pezzo per pezzo

Il frontend: 8.132 pagine che si calcolano, non si scrivono

Ogni comune della Spagna ha la sua pagina con l'ora di inizio, il massimo, la fine, la percentuale di oscuramento e, nella fascia di totalità, i secondi di buio. Questi dati non li ha scritti nessuno: si calcolano al momento di generare il sito a partire dagli elementi dell'eclissi e dalle coordinate di ciascun comune, e un test confronta un campione di risultati con quelli pubblicati dall'Instituto Geográfico Nacional. Se il calcolo si discosta, il sito non viene pubblicato. Oltre alla Spagna ci sono indici per Portogallo, Francia, Italia, Germania, Irlanda, Islanda, Groenlandia, Marocco, Paesi Bassi e Regno Unito.

Il multilingua è reale, non una traduzione automatica sovrapposta: ogni lingua ha il proprio percorso (/ca/, /en/, /de/…), i propri testi e le proprie pagine di negozio, e dei test verificano che le sette versioni di ogni template esistano e si colleghino tra loro. È la stessa regola che applichiamo su flexigotech.com e su pernocta.eu.

Il backend: una piccola API che fa da cassa, magazzino e banco

Tutto ciò che è statico lo serve nginx. Il dinamico dipende da /api/* ed è un'applicazione FastAPI con lo stato in SQLite. Sembra modesto, e lo è di proposito: lo mantiene una persona, gira su un server da pochi euro e ha retto il picco del giorno dell'eclissi senza modifiche. Le decisioni che contano sono all'interno:

• Il carrello viene valorizzato sul server. Il browser conserva le righe, ma ogni prezzo viene ricalcolato rispetto al catalogo in vigore quando si crea la sessione di pagamento. Altrimenti chiunque apre la console e si compra una felpa per un euro.
• Il webhook di Stripe comanda. Un pagamento è considerato incassato quando Stripe lo conferma con firma verificata, non quando il browser torna sulla pagina di ringraziamento. Se all'incasso fallisce l'ordine al fornitore, l'API risponde con un errore perché Stripe riprovi, e una tabella con l'identificativo di sessione evita di produrre due volte.
• Il prodotto digitale viene consegnato con un link firmato (HMAC, scade dopo 72 ore, massimo cinque download) e la casella di rinuncia al diritto di recesso è obbligatoria prima dell'incasso: l'API rifiuta il checkout del kit se non è spuntata.
• Le e-mail non si perdono. Ogni conferma parte tramite Brevo; se Brevo non risponde, resta in una coda in SQLite che un timer svuota ogni quindici minuti. Un acquirente senza e-mail di conferma è un reclamo, quindi questa regola non ha eccezioni.

Le interfacce logistiche: quattro fornitori, quattro modi di comunicare

Questa è la parte che più somiglia a ciò che ci chiedono i clienti. Il negozio vendeva cose che partivano da luoghi diversi, e ogni luogo comunicava a modo suo:

• Una tipografia con API e webhook. All'incasso, l'API genera il file di stampa (un template SVG con il nome del comune, l'ora e la durata, rasterizzato a 300 ppi), crea l'ordine e attende il webhook di «spedito» per inviare all'acquirente il suo tracciamento.
• Una seconda tipografia con stabilimento a Barcellona per l'abbigliamento, perché la prima non produceva capi in Spagna e i tempi non bastavano. Abbiamo misurato entrambe le API con ordini reali prima di decidere; la tazza è rimasta alla prima perché quella sì veniva prodotta qui.
• Un produttore di occhiali con API di dropshipping che spedisce in Spagna, Francia, Germania, Regno Unito e Portogallo. L'ordine si crea da solo all'incasso e, prima di incassare, si consulta la sua disponibilità reale per paese.
• Un distributore senza API. Spedisce gli occhiali in 24-48 ore nella Penisola e alle Baleari, ma l'ordine gli arriva per e-mail. Il pannello produce con un clic esattamente ciò che gli serve: destinatario, indirizzo, telefono, articolo e quantità, come testo e come CSV allegato. E poiché le sue spedizioni partono con GLS, l'API legge la casella ogni dieci minuti, classifica le e-mail del corriere (in viaggio, al punto di ritiro con data limite, destinatario assente) e avvisa l'acquirente di ciascuna.

Una conseguenza che sembra piccola e non lo è: un ordine con occhiali e una maglietta sono due pacchi di due fornitori. Per questo il tracciamento vive per spedizione e non per ordine, con una riga per ogni coppia ordine-fornitore. Un solo campo «numero di tracciamento» avrebbe funzionato fino al primo cliente che avesse comprato entrambe le cose.

I tempi si misurano, non si promettono

L'API di preventivo della tipografia rispondeva «consegna standard, 5-10 giorni» per tutto, anche per prodotti che poi rifiutava quando venivano ordinati davvero. Lo abbiamo scoperto con una vendita che non si è potuta consegnare. Da allora un timer crea ogni notte un ordine in bozza per ogni combinazione di prodotto e paese, legge il corriere e i giorni reali che restituisce la tipografia, e lo cancella. Quei numeri, e non quelli della documentazione, sono quelli che l'acquirente vede nella scheda prima di pagare. È la stessa lezione che applichiamo ai connettori di Odoo: un test verde contro un mock non dimostra nulla; bisogna misurare sul sistema reale.

Quello che gira da solo

Sette unità systemd fanno ciò che in un piccolo negozio di solito fa una persona a mano: leggere la casella del corriere ogni dieci minuti, svuotare le code delle e-mail e ripetere ogni quindici gli ordini incassati ma non prodotti, aggiornare ogni tre ore la previsione delle nuvole di AEMET per i comuni più consultati e misurare ogni giorno i tempi della tipografia. Nessuna chiama un servizio esterno nel percorso di una richiesta web: le pagine leggono dalla cache, e c'è un test che lo garantisce.

Cosa di tutto questo serve al tuo negozio

Quasi tutto, sostituendo l'eclissi con il tuo catalogo. Quando un cliente ci dice «voglio un sito di ecommerce da zero», chiede esattamente questa lista: un frontend veloce e multilingua, una cassa che non si possa ingannare, integrazioni con chi produce e chi spedisce, un tracciamento che arrivi al cliente senza che nessuno lo copi a mano, e attività che girano da sole. Quando il cliente ha già Odoo, quell'API la sostituisce l'ERP stesso e le integrazioni sono connettori di vettore dentro Odoo; quando non ce l'ha, o la sua attività non sta in un ERP, si costruisce come qui.

Domande frequenti

Link utili all'interno di FlexigoTech

Cosa facciamo in merito