Bastet Project: por qué he decidido desarrollar mi propio backend

Llevo tiempo trabajando en el frontend de Bastet Project. La parte visual lleva bastante recorrido, pero una tienda online no se sostiene solo con una buena interfaz: detrás tiene que existir una lógica de negocio que gestione productos, pedidos, pagos, envíos y todas esas situaciones que aparecen cuando intentas convertir una idea en algo que funcione de verdad.

Durante este tiempo he estado probando distintas plataformas de comercio electrónico para encontrar una base sobre la que construir esa parte. Después de experimentar con varias opciones, he llegado a una conclusión: para lo que quiero hacer con Bastet, prefiero desarrollar un backend propio.

No es una decisión porque sí, ni significa que las plataformas que he probado sean malas en términos generales. Simplemente, no he encontrado una que encaje bien con mis necesidades concretas.

Probar antes de decidir

Una de las opciones que probé fue Medusa. Me pareció una alternativa interesante para construir un comercio electrónico con una arquitectura más flexible, pero al llevarla a mis casos de uso empecé a encontrar limitaciones y trabajo adicional en áreas que para mí son fundamentales, especialmente la gestión de los envíos. No quería acabar adaptando continuamente el proyecto a la forma de trabajar de la plataforma.

También estuve mirando Odoo. Tiene un enfoque amplio y reúne muchas herramientas, pero la experiencia no me resultó suficientemente intuitiva para el flujo de trabajo que buscaba. Tener muchas funcionalidades no significa necesariamente que la solución sea la adecuada para un proyecto personal.

Con PrestaShop, por otro lado, me encontré con errores durante la instalación y otros problemas que me dificultaron avanzar con la configuración. Es posible que parte de esos problemas dependieran de mi entorno o de la instalación concreta; no pretendo convertir una experiencia personal en una conclusión universal sobre la plataforma.

Las pruebas me han servido para entender mejor qué necesito. También me han dejado claro que elegir una herramienta conocida no siempre es el camino más corto si después tienes que luchar contra sus decisiones de diseño.

No quiero reconstruir una tienda genérica

La idea no es crear otra plataforma de comercio electrónico que copie las funciones habituales y ya está. Quiero construir una solución pensada para las necesidades reales de Bastet Project, incluyendo capacidades específicas desde el principio cuando aporten valor al proyecto.

Eso implica tratar los pagos y los envíos como partes centrales del sistema, no como añadidos que se resuelven al final. Quiero poder definir cómo encajan los métodos de pago, cómo se calculan o aplican los costes de envío, qué ocurre con los estados de un pedido y cómo se conectan esas piezas con el resto de la tienda.

También necesito una base para gestionar el catálogo, los clientes y los pedidos, además de una integración clara con el frontend que ya existe. Y, sobre todo, quiero que la arquitectura permita añadir funciones nuevas sin tener que rehacer todo cada vez que cambie una necesidad.

No significa que vaya a desarrollar absolutamente todo desde cero, incluidos servicios que no tenga sentido mantener por mi cuenta. En áreas como los pagos, la prioridad será integrar soluciones adecuadas y construir alrededor de ellas la lógica específica que necesita el proyecto. La meta es controlar el comportamiento de la tienda, no reinventar sistemas que ya tienen sentido como servicios externos.

La ventaja y el coste de hacerlo a medida

Un backend propio ofrece libertad para decidir cómo se modelan los datos, cómo se conectan los módulos y qué reglas debe seguir el negocio. Puedo priorizar las funciones que necesito de verdad, en lugar de adaptar cada proceso a un sistema genérico.

Pero esa libertad tiene un precio: la responsabilidad también pasa a ser mía. Hay que diseñar bien los permisos, validar las operaciones, gestionar errores, proteger los datos y probar los casos límite. En pagos y pedidos, especialmente, no basta con que el flujo funcione una vez; tiene que comportarse de forma coherente cuando algo falla, se repite o llega fuera de orden.

Por eso no quiero presentar esta decisión como una solución mágica ni como una forma de terminar antes. Probablemente haya más trabajo al principio. La apuesta es que una base diseñada alrededor del proyecto me permita avanzar con menos fricción a largo plazo y construir funcionalidades que realmente necesito.

Una nueva parte del proyecto: Bastet Core

Para separar esta parte del trabajo he decidido plantear Bastet Core como proyecto secundario: el espacio dedicado al backend y a la lógica que hará funcionar la tienda.

Bastet Project seguirá siendo el proyecto principal, con su identidad, su experiencia de usuario y su frontend. Bastet Core se centrará en la arquitectura de servidor, la lógica de negocio y las integraciones. La separación es conceptual por ahora; no quiero dar a entender que ya exista una arquitectura desplegada o que estas funcionalidades estén terminadas.

Entre los objetivos iniciales están:

• Gestionar productos, clientes y pedidos.
• Diseñar un flujo de pago fiable mediante integraciones apropiadas.
• Controlar los métodos, las reglas y los costes de envío.
• Mantener sincronizados los estados relevantes entre los procesos de compra.
• Exponer una API clara para el frontend existente.
• Organizar el sistema en módulos que puedan evolucionar de forma independiente.
• Añadir capacidades específicas de Bastet cuando las necesidades reales lo justifiquen.

La tecnología y los detalles de arquitectura se concretarán a medida que valide los requisitos. Prefiero tomar esas decisiones con los casos de uso delante, en lugar de elegir un stack solo porque esté de moda.

Lo que viene ahora

El siguiente paso es convertir esta decisión en una base técnica bien definida: concretar los flujos principales, delimitar los módulos y priorizar qué necesita estar resuelto para poder recorrer una compra de principio a fin. Después tocará implementar, probar y revisar cada parte con cuidado, especialmente todo lo relacionado con pagos, pedidos y envíos.

De momento, el backend propio es una decisión de diseño, no una promesa de que todo esté construido. Iré compartiendo lo que funcione, los problemas que aparezcan y los cambios de rumbo que tengan sentido.

Al final, las pruebas con Medusa, Odoo y PrestaShop no han sido tiempo perdido. Me han ayudado a detectar qué no encajaba y a definir mejor qué quiero construir. Ahora toca pasar de buscar una plataforma que se adapte a Bastet a diseñar una base que nazca de las necesidades de Bastet.

Ese es el objetivo de Bastet Core: no hacer más por hacer más, sino construir las capacidades adecuadas y hacerlas bien.