Cas d'èxit: eclipseando.com, una web i un backend d'ecommerce fets de zero en 19 dies

El 12 d'agost de 2026 hi va haver un eclipsi total de sol sobre Espanya. El 24 de juliol eclipseando.com no existia: ni domini, ni disseny, ni una línia de codi. Dinou dies després la web estava publicada amb una pàgina per a cada municipi d'Espanya, una botiga que cobrava amb Stripe i una cadena de logística que feia comandes a quatre proveïdors diferents. Ho expliquem aquí perquè és el projecte que millor mostra com treballem quan l'encàrrec és «una web i un backend de zero», i perquè cada peça està en producció i es pot visitar.

L'encàrrec: una web amb data de caducitat

El projecte era nostre, no d'un client, i això el fa més honest com a exemple: no hi havia pressupost que estirar ni termini negociable. La data la posava el cel. Els requisits van sortir d'una investigació prèvia i eren concrets: respondre «a quina hora i quant es veu des del meu poble?» per a qualsevol municipi d'Espanya, vendre ulleres certificades i records personalitzats per municipi, i fer-ho també en català, anglès, alemany, francès, italià i portuguès, perquè part del públic venia de fora.

Vam descartar Shopify i WooCommerce abans de començar. No per preu, sinó perquè el difícil del projecte no era la botiga: eren les 8.132 pàgines calculades, el mapa, la previsió de núvols i unes integracions logístiques que cap plataforma porta de sèrie. Quan el valor és en allò que no ve de sèrie, la plataforma destorba més del que ajuda. Aquest mateix criteri l'apliquem quan un client ens pregunta si ha de fer la seva web sobre Odoo Website o a part.

Què es va construir, peça a peça

El frontal: 8.132 pàgines que es calculen, no s'escriuen

Cada municipi d'Espanya té la seva pàgina amb l'hora d'inici, el màxim, el final, el percentatge d'ocultació i, a la franja de totalitat, els segons d'foscor. Aquestes dades no les va escriure ningú: es calculen en el moment de generar el lloc a partir dels elements de l'eclipsi i les coordenades de cada municipi, i hi ha un test que contrasta una mostra de resultats amb els que publica l'Instituto Geográfico Nacional. Si el càlcul es desvia, la web no es publica. A més d'Espanya hi ha índexs per a Portugal, França, Itàlia, Alemanya, Irlanda, Islàndia, Groenlàndia, el Marroc, els Països Baixos i el Regne Unit.

El multiidioma és real, no una traducció automàtica superposada: cada idioma té la seva pròpia ruta (/ca/, /en/, /de/…), els seus propis textos i les seves pròpies pàgines de botiga, i hi ha tests que comproven que les set versions de cada plantilla existeixen i s'enllacen entre elles. És la mateixa regla que apliquem a flexigotech.com i a pernocta.eu.

El backend: una API petita que fa de caixa, magatzem i taulell

Tot l'estàtic ho serveix nginx. El dinàmic penja de /api/* i és una aplicació FastAPI amb l'estat en SQLite. Sona modest, i ho és a propòsit: el manté una persona, corre en un servidor de pocs euros i va aguantar el pic del dia de l'eclipsi sense canviar res. Les decisions que importen són a dins:

• La cistella es valora al servidor. El navegador guarda les línies, però cada preu es recalcula contra el catàleg vigent en crear la sessió de pagament. Si no, qualsevol obre la consola i es compra una dessuadora per un euro.
• El webhook de Stripe mana. Un pagament es considera cobrat quan Stripe el confirma amb signatura verificada, no quan el navegador torna a la pàgina de gràcies. Si en cobrar falla la comanda al proveïdor, l'API respon error perquè Stripe reintenti, i una taula amb l'identificador de sessió evita fabricar dues vegades.
• El producte digital es lliura amb un enllaç signat (HMAC, caduca a les 72 hores, cinc descàrregues com a màxim) i la casella de renúncia al desistiment s'exigeix abans de cobrar: l'API rebutja el checkout del kit si no ve marcada.
• Els correus no es perden. Cada confirmació surt per Brevo; si Brevo no respon, queda en una cua a SQLite que un temporitzador buida cada quinze minuts. Un comprador sense el seu correu de confirmació és una reclamació, així que aquesta regla no té excepcions.

Les interfícies de logística: quatre proveïdors, quatre maneres de parlar

Aquí hi ha la part que més s'assembla al que ens demanen els clients. La botiga venia coses que sortien de llocs diferents, i cada lloc es comunicava a la seva manera:

• Una impremta amb API i webhook. En cobrar, l'API genera el fitxer d'impressió (una plantilla SVG amb el nom del municipi, l'hora i la durada, rasteritzada a 300 ppp), crea la comanda i espera el webhook d'«enviat» per enviar al comprador el seu seguiment.
• Una segona impremta amb planta a Barcelona per a la roba, perquè la primera no fabricava peces a Espanya i el termini no arribava. Es va mesurar contra les dues API amb comandes reals abans de decidir; la tassa es va quedar a la primera perquè aquesta sí que es fabricava aquí.
• Un fabricant d'ulleres amb API de dropshipping que envia a Espanya, França, Alemanya, el Regne Unit i Portugal. La comanda es crea sola en cobrar, i abans de cobrar es consulta la seva disponibilitat real per país.
• Un distribuïdor sense API. Envia les ulleres en 24-48 hores dins de la Península i Balears, però la comanda se li passa per correu. El panell produeix en un clic exactament el que necessita: destinatari, adreça, telèfon, article i quantitat, com a text i com a CSV adjunt. I com que els seus enviaments surten amb GLS, l'API llegeix la bústia cada deu minuts, classifica els correus del transportista (en camí, en punt de recollida amb data límit, absent) i avisa el comprador de cadascun.

Una conseqüència que sembla petita i no ho és: una comanda amb ulleres i una samarreta són dos paquets de dos proveïdors. Per això el seguiment viu per enviament i no per comanda, amb una fila per cada parella comanda-proveïdor. Un sol camp «número de seguiment» hauria funcionat fins al primer client que comprés les dues coses.

Els terminis es mesuren, no es prometen

L'API de cotització de la impremta responia «lliurament estàndard, 5-10 dies» per a tot, fins i tot per a productes que després rebutjava en demanar-los de debò. Ho vam descobrir amb una venda que no va poder lliurar-se. Des de llavors un temporitzador crea cada matinada una comanda en esborrany per cada combinació de producte i país, llegeix el transportista i els dies reals que retorna la impremta, i l'esborra. Aquests números, i no els de la documentació, són els que veu el comprador a la fitxa abans de pagar. És la mateixa lliçó que apliquem als connectors d'Odoo: un test verd contra un mock no prova res; cal mesurar contra el sistema real.

Allò que corre sol

Set unitats de systemd fan el que en una botiga petita sol fer una persona a mà: llegir la bústia del transportista cada deu minuts, buidar les cues de correu i reintentar les comandes cobrades sense fabricar cada quinze, refrescar cada tres hores la previsió de núvols d'AEMET per als municipis més consultats i mesurar cada dia els terminis de la impremta. Cap crida un servei extern en el camí d'una petició web: les pàgines llegeixen memòria cau, i hi ha un test que ho garanteix.

Què d'això serveix per a la teva botiga

Gairebé tot, canviant l'eclipsi pel teu catàleg. El que un client ens demana quan diu «vull una web d'ecommerce de zero» és exactament aquesta llista: un frontal ràpid i multiidioma, una caixa que no es pugui enganyar, integracions amb qui fabrica i qui envia, seguiment que arribi al client sense que ningú el copiï a mà, i tasques que corrin soles. Quan el client ja té Odoo, aquesta API la substitueix el mateix ERP i les integracions són connectors de transportista dins d'Odoo; quan no el té, o el seu negoci no cap en un ERP, es construeix com aquí.

Preguntes freqüents

Enllaços útils dins de FlexigoTech

El que fem sobre això