El 12 de agosto de 2026 hubo un eclipse total de sol sobre España. El 24 de julio no existía eclipseando.com: ni dominio, ni diseño, ni una línea de código. Diecinueve días después la web estaba publicada con una página por cada municipio de España, una tienda que cobraba con Stripe y una cadena de logística que hacía pedidos a cuatro proveedores distintos. Lo contamos aquí porque es el proyecto que mejor enseña cómo trabajamos cuando el encargo es «una web y un backend de cero», y porque cada pieza está en producción y se puede visitar.
Idea clave: una web de ecommerce no es una plantilla con un botón de pago. Es el frontal, la caja, el almacén de datos y las interfaces con quien fabrica y quien envía. En eclipseando.com esas cuatro capas las escribimos nosotros, y cada una está probada con tests que se ejecutan antes de publicar.
El encargo: una web con fecha de caducidad
El proyecto era nuestro, no de un cliente, y eso lo hace más honesto como ejemplo: no había presupuesto que estirar ni plazo negociable. La fecha la ponía el cielo. Los requisitos salieron de una investigación previa y eran concretos: responder «¿a qué hora y cuánto se ve desde mi pueblo?» para cualquier municipio de España, vender gafas certificadas y recuerdos personalizados por municipio, y hacerlo también en catalán, inglés, alemán, francés, italiano y portugués, porque parte del público venía de fuera.
Descartamos Shopify y WooCommerce antes de empezar. No por precio, sino porque lo difícil del proyecto no era la tienda: eran las 8.132 páginas calculadas, el mapa, la previsión de nubes y unas integraciones logísticas que ninguna plataforma trae de serie. Cuando el valor está en lo que no viene de serie, la plataforma estorba más de lo que ayuda. Ese mismo criterio lo aplicamos cuando un cliente nos pregunta si hacer su web sobre Odoo Website o aparte.
Qué se construyó, pieza a pieza
| Pieza | Qué hace | Con qué está hecha |
|---|---|---|
| Frontal | 8.132 páginas de municipio, mapa, buscador, tienda y blog, en siete idiomas con URL propia por idioma. | Sitio estático generado con Astro; servido por nginx en un servidor propio. |
| API | Cesta, checkout, entrega del kit digital, pedidos a proveedores, seguimiento, newsletter, nubes por municipio, analítica sin cookies y panel de gestión. | FastAPI en Python, estado en SQLite, 1.370 tests automáticos. |
| Cobro | Stripe Checkout con webhook firmado; el precio se calcula siempre en el servidor, nunca en el navegador. | API de Stripe; idioma de la pasarela según la tienda desde la que se compra. |
| Logística | Cuatro proveedores: dos con API, uno con API de dropshipping y uno sin API al que se le pasa el pedido por correo y CSV. | Integraciones propias, lectura del buzón del transportista y avisos al comprador. |
| Tareas programadas | Siete temporizadores: buzón, colas, reintentos, nubes, plazos de la imprenta y parte del cielo. | Unidades systemd en el mismo servidor. |
El frontal: 8.132 páginas que se calculan, no se escriben
Cada municipio de España tiene su página con la hora de inicio, el máximo, el final, el porcentaje de ocultación y, en la franja de totalidad, los segundos de oscuridad. Esos datos no los escribió nadie: se calculan en el momento de generar el sitio a partir de los elementos del eclipse y las coordenadas de cada municipio, y hay un test que contrasta una muestra de resultados con los que publica el Instituto Geográfico Nacional. Si el cálculo se desvía, la web no se publica. Además de España hay índices para Portugal, Francia, Italia, Alemania, Irlanda, Islandia, Groenlandia, Marruecos, Países Bajos y Reino Unido.
El multiidioma es real, no una traducción automática superpuesta: cada idioma tiene su propia ruta (/ca/, /en/, /de/…), sus propios textos y sus propias páginas de tienda, y hay tests que comprueban que las siete versiones de cada plantilla existen y enlazan entre sí. Es la misma regla que aplicamos en flexigotech.com y en pernocta.eu.
El backend: una API pequeña que hace de caja, almacén y mostrador
Todo lo estático lo sirve nginx. Lo dinámico cuelga de /api/* y es una aplicación FastAPI con el estado en SQLite. Suena modesto, y lo es a propósito: lo mantiene una persona, corre en un servidor de pocos euros y aguantó el pico del día del eclipse sin cambiar nada. Las decisiones que importan están dentro:
- La cesta se valora en el servidor. El navegador guarda las líneas, pero cada precio se recalcula contra el catálogo vigente al crear la sesión de pago. Si no, cualquiera abre la consola y se compra una sudadera por un euro.
- El webhook de Stripe manda. Un pago se considera cobrado cuando Stripe lo confirma con firma verificada, no cuando el navegador vuelve a la página de gracias. Si al cobrar falla el pedido al proveedor, la API responde error para que Stripe reintente, y una tabla con el identificador de sesión evita fabricar dos veces.
- El producto digital se entrega con un enlace firmado (HMAC, caduca a las 72 horas, cinco descargas como máximo) y la casilla de renuncia al desistimiento se exige antes de cobrar: la API rechaza el checkout del kit si no viene marcada.
- Los correos no se pierden. Cada confirmación sale por Brevo; si Brevo no responde, queda en una cola en SQLite que un temporizador vacía cada quince minutos. Un comprador sin su correo de confirmación es una reclamación, así que esa regla no tiene excepciones.
Las interfaces de logística: cuatro proveedores, cuatro maneras de hablar
Aquí está la parte que más se parece a lo que nos piden los clientes. La tienda vendía cosas que salían de sitios distintos, y cada sitio se comunicaba a su manera:
- Una imprenta con API y webhook. Al cobrar, la API genera el fichero de impresión (una plantilla SVG con el nombre del municipio, la hora y la duración, rasterizada a 300 ppp), crea el pedido y espera el webhook de «enviado» para mandar al comprador su seguimiento.
- Una segunda imprenta con planta en Barcelona para la ropa, porque la primera no fabricaba prendas en España y el plazo no llegaba. Se midió contra las dos API con pedidos reales antes de decidir; la taza se quedó en la primera porque esa sí se fabricaba aquí.
- Un fabricante de gafas con API de dropshipping que envía a España, Francia, Alemania, Reino Unido y Portugal. El pedido se crea solo al cobrar, y antes de cobrar se consulta su disponibilidad real por país.
- Un distribuidor sin API. Envía las gafas en 24-48 horas dentro de la Península y Baleares, pero el pedido se le pasa por correo. El panel produce en un clic exactamente lo que necesita: destinatario, dirección, teléfono, artículo y cantidad, como texto y como CSV adjunto. Y como sus envíos salen con GLS, la API lee el buzón cada diez minutos, clasifica los correos del transportista (en camino, en punto de recogida con fecha límite, ausente) y avisa al comprador de cada uno.
Una consecuencia que parece pequeña y no lo es: un pedido con gafas y una camiseta son dos paquetes de dos proveedores. Por eso el seguimiento vive por envío y no por pedido, con una fila por cada pareja pedido-proveedor. Un solo campo «número de seguimiento» habría funcionado hasta el primer cliente que comprara las dos cosas.
Los plazos se miden, no se prometen
La API de cotización de la imprenta respondía «entrega estándar, 5-10 días» para todo, incluso para productos que luego rechazaba al pedirlos de verdad. Lo descubrimos con una venta que no pudo entregarse. Desde entonces un temporizador crea cada madrugada un pedido en borrador por cada combinación de producto y país, lee el transportista y los días reales que devuelve la imprenta, y lo borra. Esos números, y no los de la documentación, son los que ve el comprador en la ficha antes de pagar. Es la misma lección que aplicamos a los conectores de Odoo: un test verde contra un mock no prueba nada; hay que medir contra el sistema real.
Lo que corre solo
Siete unidades de systemd hacen lo que en una tienda pequeña suele hacer una persona a mano: leer el buzón del transportista cada diez minutos, vaciar las colas de correo y reintentar los pedidos cobrados sin fabricar cada quince, refrescar cada tres horas la previsión de nubes de AEMET para los municipios más consultados y medir a diario los plazos de la imprenta. Ninguna llama a un servicio externo en el camino de una petición web: las páginas leen caché, y hay un test que lo garantiza.
Qué de esto sirve para tu tienda
Casi todo, cambiando el eclipse por tu catálogo. Lo que un cliente nos pide cuando dice «quiero una web de ecommerce de cero» es exactamente esta lista: un frontal rápido y multiidioma, una caja que no se pueda engañar, integraciones con quien fabrica y quien envía, seguimiento que llegue al cliente sin que nadie lo copie a mano, y tareas que corran solas. Cuando el cliente ya tiene Odoo, esa API la sustituye el propio ERP y las integraciones son conectores de transportista dentro de Odoo; cuando no lo tiene, o su negocio no cabe en un ERP, se construye como aquí.
Preguntas frecuentes
¿Por qué no se hizo con Shopify o WooCommerce?
Porque lo difícil no era la tienda sino lo que la rodeaba: 8.132 páginas calculadas, un mapa propio, previsión meteorológica y cuatro integraciones logísticas distintas. Cuando el valor está en lo que la plataforma no trae, la plataforma es un coste fijo que además limita. La tienda en sí, con Stripe Checkout, fue una parte pequeña del trabajo.
¿Cómo se integra un proveedor que no tiene API?
Reduciendo el trabajo humano a un clic y automatizando lo que sí llega por un canal legible. En eclipseando.com el pedido al distribuidor de gafas sale del panel como texto y CSV listos para pegar en un correo, y los avisos del transportista se leen del buzón cada diez minutos y se convierten en estados y correos al comprador.
¿Se puede hacer lo mismo sobre Odoo?
Sí, y es lo habitual cuando el cliente ya tiene el ERP: el frontal se conecta a Odoo, la cesta y el pedido viven en ventas, y los transportistas entran por conectores publicados en el App Store. Se construye aparte cuando no hay Odoo o cuando el núcleo del negocio, como aquí, no es un catálogo sino un cálculo.
Enlaces útiles dentro de FlexigoTech
¿Necesitas una web o una tienda hecha de cero, con su logística conectada?
Cuéntanos qué vendes, quién lo fabrica y quién lo envía. Te decimos qué se construye, qué se integra por API y qué no hace falta programar. Escribe a comercial@flexigobe.com o llama al +34 616 809 504.