«Quiero una tienda online hecha de cero» suele significar «quiero una tienda que haga lo que las plantillas no hacen». Y lo que las plantillas no hacen es casi siempre lo mismo: hablar con quien fabrica, con quien envía y con quien cobra, sin que una persona copie datos de una pantalla a otra. Este artículo explica cómo estructuramos ese trabajo en cinco capas, qué lleva cada una y en qué orden se construyen. Los ejemplos son de eclipseando.com, una tienda nuestra que está en producción, y de los conectores de transportista que tenemos publicados para Odoo.
Idea clave: el frontal es la capa más visible y la menos arriesgada. Donde se pierde dinero es en las tres del medio: una caja que se puede engañar, unos datos que viven en dos sitios y un proveedor al que se le pasan los pedidos a mano. Se construye de dentro hacia fuera.
Las cinco capas de una tienda
| Capa | Qué contiene | Error típico cuando se salta |
|---|---|---|
| 1 · Datos | Catálogo, precios, stock, pedidos, clientes. Una sola fuente de verdad. | El precio en la web y el precio en el ERP se separan a los dos meses. |
| 2 · Caja | Cesta, cálculo de precio y envío, pasarela, confirmación del pago por webhook. | Se confía en la página de gracias y se prepara un pedido que nunca se cobró. |
| 3 · Proveedores | Fabricante, almacén, transportista: pedido de salida, etiqueta, seguimiento, incidencias. | El tracking se copia a mano y llega al cliente, si llega, un día tarde. |
| 4 · Tareas programadas | Colas, reintentos, lectura de buzones, sincronización de stock, recordatorios. | Un correo que falla una noche se pierde para siempre. |
| 5 · Frontal | Páginas, fichas, buscador, idiomas, velocidad, SEO. | Se empieza por aquí, se enseña bonito, y las otras cuatro se improvisan después. |
Capa 1: los datos viven en un solo sitio
Antes de dibujar una pantalla hay que decidir dónde vive el catálogo. Si el cliente tiene Odoo, la respuesta es Odoo: productos, precios, stock y pedidos están ahí y la web los lee, no los copia. Si no lo tiene, la tienda necesita su propia base de datos, y conviene que sea pequeña y aburrida. En eclipseando.com es SQLite, en un fichero, con copia de seguridad. Lo que no puede pasar es que el precio esté en la web y también en una hoja de cálculo y también en el ERP: a los dos meses son tres precios distintos.
Capa 2: la caja no se fía del navegador
Dos reglas que no negociamos. La primera: el precio se calcula en el servidor, con el catálogo vigente, en el momento de crear la sesión de pago. El navegador puede guardar la cesta, pero no puede decir cuánto vale. La segunda: un pedido está cobrado cuando la pasarela lo confirma con un webhook firmado, no cuando el cliente aterriza en la página de gracias. Con Stripe eso es checkout.session.completed con la firma verificada; con otras pasarelas tiene otro nombre y la misma idea. Y si al recibir el webhook falla el paso siguiente, se responde error para que la pasarela reintente, y se guarda el identificador de sesión para no fabricar dos veces.
Capa 3: cada proveedor habla como puede
Aquí es donde «integración logística» deja de ser una palabra y se convierte en trabajo. Un proveedor con API y webhook (una imprenta bajo demanda, un transportista grande) se integra en los dos sentidos: se le crea el pedido al cobrar y se escucha su aviso de «enviado» para pasar el seguimiento al cliente. Uno con API de dropshipping se integra en un sentido y se consulta en el otro: antes de cobrar, la disponibilidad real por país; después, el pedido. Y uno sin API, que los hay y muchos, se integra reduciendo el trabajo humano a un clic: el sistema produce exactamente el correo o el CSV que el proveedor necesita, y si sus paquetes salen con un transportista que manda correos, esos correos se leen y se convierten en estados.
Dos detalles que solo se aprenden con pedidos reales. Uno: el seguimiento va por envío, no por pedido, porque un pedido con dos productos de dos proveedores son dos paquetes. Dos: los plazos que dice la documentación del proveedor no son los que cumple; se miden creando pedidos de prueba y leyendo lo que devuelve, y esos son los que se enseñan al cliente antes de pagar. Cuando el proveedor es un transportista y la tienda lleva Odoo, todo esto ya está resuelto en los conectores de transportista que publicamos: etiqueta, seguimiento, manifiesto y devolución dentro del albarán.
Capa 4: lo que corre solo y lo que se reintenta
Una tienda tiene trabajo que no puede depender de que alguien lo recuerde: vaciar la cola de correos, reintentar los pedidos cobrados que no llegaron al proveedor, leer el buzón del transportista, sincronizar el stock con los marketplaces. Cada uno es una tarea programada con un intervalo y un registro. La regla de diseño es que ninguna llame a un servicio externo en el camino de una petición del usuario: la página lee lo que la tarea dejó en caché. Así, si el proveedor se cae a las tres de la mañana, la tienda sigue sirviendo páginas y los pedidos se reintentan cuando vuelva.
Capa 5: el frontal, al final y rápido
Con las cuatro capas de abajo resueltas, el frontal es la parte más agradecida. Preferimos sitios estáticos generados en build (Astro en eclipseando.com) servidos por nginx o Caddy: cargan en nada, no tienen base de datos que atacar y cuestan lo que cuesta un servidor pequeño. Lo dinámico (cesta, pago, estado del pedido) va por una API aparte. El multiidioma se hace con una URL por idioma y textos propios, no con un traductor automático encima, y se prueba con tests que comprueban que cada plantilla existe en todos los idiomas. Y la velocidad se mide antes de publicar: peso de página, imágenes en el tamaño que se pintan, nada que bloquee el primer render.
El orden importa: de dentro hacia fuera
El error más caro que vemos es empezar por la capa 5. Se enseña una web bonita en la segunda semana, el cliente se ilusiona, y las capas 1 a 4 se improvisan debajo con prisa. El resultado funciona hasta el primer pedido con dos proveedores, o hasta el primer webhook perdido. Nosotros construimos al revés: primero los datos y la caja con sus tests, después las integraciones con pedidos de prueba reales, después las tareas programadas, y el frontal al final, cuando ya se sabe exactamente qué tiene que enseñar. Tarda lo mismo. Se rehace mucho menos.
Preguntas frecuentes
¿Cuándo tiene sentido hacer la tienda de cero en lugar de usar Shopify o Odoo Website?
Cuando el valor está en lo que la plataforma no trae: un cálculo propio, integraciones con proveedores sin conector, un catálogo que no es un catálogo. Si tu tienda es un catálogo normal con un transportista normal, una plataforma es más barata y la respuesta correcta. Lo desarrollamos en cuándo hacer la web sobre Odoo Website y cuándo no.
¿Qué pasa con un proveedor que no tiene API?
Se integra igual, con otro canal: el sistema genera el correo o el CSV exacto que necesita, en un clic, y lee lo que el proveedor o su transportista devuelvan por correo. No es tan limpio como una API, pero elimina la copia manual, que es donde se cometen los errores.
¿Y si ya tengo Odoo?
Entonces las capas 1, 3 y 4 ya existen en gran parte: el catálogo y los pedidos viven en Odoo, los transportistas entran por conectores publicados y las tareas programadas son crons del propio ERP. Lo que se construye es el frontal y, si hace falta, una caja a medida conectada a ventas.
Enlaces útiles dentro de FlexigoTech
¿Tienes una tienda en la cabeza que no cabe en una plantilla?
Cuéntanos qué vendes, quién lo fabrica y quién lo envía. Te devolvemos las cinco capas con lo que va en cada una y en qué orden. Escribe a comercial@flexigobe.com o llama al +34 616 809 504.