Delicaté 4.0

01Contexto

Delicaté es una marca de jabones artesanales hechos en pequeñas tandas en República Dominicana, y el sitio lo hice para ella. Vende por conversación: el cliente pregunta, elige y coordina la entrega por WhatsApp. El sitio tenía que presentar la marca y el catálogo con una experiencia propia y llevar al cliente a esa conversación con el pedido ya armado.

El repositorio conserva dos generaciones. La de 2024 era una tienda convencional: registro e inicio de sesión con Google, carrito guardado en el servidor, reseñas, historial de pedidos y blog. La 4.0, reconstruida en agosto de 2026 y en producción desde septiembre, parte de preguntar qué necesitaba de verdad el negocio.

02Problema

Una tienda con cuentas, checkout, pagos e inventario promete una operación que este negocio no tiene. Pedir registro para comprar un jabón añade fricción sin aportar nada, y un checkout que no puede cobrar es una promesa rota. Lo que sí hacía falta era mostrar bien los productos, ayudar a elegir y recibir un pedido claro, porque la confirmación, el cobro y la entrega seguirían ocurriendo por WhatsApp.

03Mi función

Levanté las necesidades con el negocio, definí la arquitectura de información y el recorrido, diseñé la interfaz y desarrollé la tienda, la API y la administración. También la desplegué con su dominio y escribí la documentación técnica, la lista de salida a producción y la especificación de una futura línea de jabones personalizados.

04Usuarios

El comprador explora la colección, filtra por categoría, abre la ficha de cada jabón y arma su pedido sin crear una cuenta. El equipo del negocio mantiene productos, precios, existencias, fotografías y destacados desde el administrador de Django, y recibe en WhatsApp un mensaje legible con cada producto, su cantidad y el total.

05Restricciones

• Sin pagos, sin logística y sin prometer existencias en tiempo real. Por eso el total del carrito es «estimado».
• Un catálogo que cambia sin recompilar nada. La tienda lo lee de la API en cada visita.
• Primero el teléfono. Es donde compra el público de la marca y donde vive WhatsApp.
• Ningún dato de compradores. La tienda no guarda perfiles, direcciones ni pedidos.

06Cómo lo construí

Partí del recorrido comercial real —descubrir la marca, encontrar un producto, entender sus beneficios, armar el pedido y abrir la conversación— y retiré todo lo que no servía a ese recorrido. La reconstrucción eliminó los modelos de la versión anterior con migraciones explícitas (carrito, líneas de carrito, reseñas y perfiles de usuario) y añadió una migración de datos para dar a cada producto un slug único. Pasó de ocho modelos a cuatro y de treinta dependencias de ejecución en el frontend a dos: React y React DOM.

El backend son tres aplicaciones de Django: shop (catálogo, API y administración), contact (mensajes y suscripciones) y accounts (el usuario del equipo, que entra con su correo). El frontend son seis componentes de React, un hook para el carrito y CSS propio, sin librerías de estado ni de componentes. En septiembre de 2026 la preparé para producción: endurecí Django, hice que el carrito se sincronizara con el catálogo y la desplegué con su dominio.

07Decisiones de arquitectura

• Sin cuentas de cliente. El usuario personalizado de Django existe sólo para el equipo; el comprador nunca se registra.
• API pública de sólo lectura. El catálogo se consulta por la API y se escribe únicamente desde el administrador. La tienda pide todas las páginas del listado, así que un catálogo más grande no deja productos fuera.
• Un carrito que no miente. Vive en localStorage y sobrevive a la recarga. Al llegar el catálogo, cada línea toma el precio actual, su cantidad se limita a las existencias y los productos retirados salen del carrito; si algo cambió, el cajón lo dice.
• Un solo contenedor en producción. Django sirve la API, el administrador, las fotos y el build de React desde el mismo dominio, con WhiteNoise: no hace falta CORS. En desarrollo, Vite hace de proxy hacia Django.
• La demostración nunca sustituye a los datos reales. El catálogo de respaldo sólo aparece en desarrollo o si se activa explícitamente, con un aviso visible. En producción, si la API falla, el cliente ve un error con reintento, no productos inventados.

08El pedido por WhatsApp

«Finalizar por WhatsApp» abre un enlace wa.me con el pedido ya escrito. No hay integración con la API de WhatsApp ni nada que pagar por mensaje: el servidor no registra el pedido y la conversación sigue en el teléfono del negocio. Éste es el mensaje que genera el carrito de las capturas:

¡Hola, Delicaté!
Quiero realizar este pedido:

• 2 × Avena Calma — RD$700
• 1 × Corazón de Lavanda — RD$425
• 1 × Café Despierto — RD$450

Total estimado: RD$1,575

Mi nombre es:
Prefiero: entrega / recoger

¿Me confirman disponibilidad y forma de entrega? Gracias.

El saludo llevaba un emoji que la página web de WhatsApp convertía en «�» al redirigir el enlace; ahora va sin él. El formulario de contacto hace lo mismo con el nombre y la consulta: tampoco guarda nada en el servidor.

09Producción y seguridad

• Publicar sólo lo que funciona. Cada push a main construye la imagen, aplica las migraciones antes de publicar y sólo da tráfico a la versión nueva si /api/health/, que consulta la base de datos, responde 200. Si algo falla, sigue la anterior.
• Cabeceras en todas las respuestas, también en las que sirve WhiteNoise: política de seguridad de contenidos, Permissions-Policy y X-Frame-Options; HTTPS obligatorio, HSTS de un año y cookies seguras.
• Límites de frecuencia que cuentan la IP real detrás del proxy: mil peticiones por hora y visitante, y topes propios para los endpoints de escritura.
• Arranque seguro. Con DEBUG apagado, Django se niega a arrancar con la clave de desarrollo o con una ruta de fotos relativa.
• Fotos validadas por formato (JPG, PNG, WebP) y peso (5 MB), y servidas con caché de siete días.

10Desafíos

El principal fue construir una experiencia de compra convincente sin fingir una infraestructura de pagos o logística. El segundo, mantener coherentes el catálogo administrado, los filtros, la ficha y un carrito que sobrevive entre visitas cuando cambian los precios o las existencias. Y el tercero fue reducir: pasar de una tienda sobredimensionada a un producto de unas 2.600 líneas que se puede mantener.

11Lo que enseñó el despliegue

• Railway no aplicó railway.json al servicio creado desde la línea de comandos, y la primera versión salió sin migraciones. La configuración quedó fijada en el propio servicio.
• Git Bash convirtió la ruta /data/media en una ruta de Windows y las fotos se perdieron en un redespliegue. Lo corregí y añadí la validación que hoy impide arrancar con una ruta relativa.
• Al añadir el dominio propio, Railway dejó de exponer la dirección *.up.railway.app; ahora los dos hosts están autorizados de forma explícita.

12Diseño y UX

La dirección visual usa una paleta cálida de crema, verde bosque y terracota, una serif editorial para los titulares y mucho aire para comunicar artesanía, sin descargar fuentes web. La página cuenta una historia en orden: portada, valores, colección, historia de la marca, cómo pedir en tres pasos, preguntas frecuentes y contacto. Al agregar un producto, el carrito se abre para confirmar el gesto.

Los estados están resueltos: carga, error con reintento, categoría vacía y producto agotado. En accesibilidad, la ficha es un <dialog> nativo, el carrito atrapa y devuelve el foco, el menú móvil se cierra con Escape, hay enlace para saltar al contenido, los filtros declaran su estado con aria-pressed y se respeta prefers-reduced-motion.

13Lo que no tiene

Para que nadie lo dé por supuesto: no hay pagos, ni búsqueda en la tienda (sólo la API acepta ?search=), ni variantes de producto, ni más de una foto por producto, ni una página propia con URL para cada jabón: la ficha es un diálogo. Tampoco hay panel de pedidos, porque los pedidos no pasan por el servidor. La API conserva dos endpoints de contacto y boletín, con límite de frecuencia, que ninguna pantalla de la tienda usa hoy.

14Sobre las capturas

Las capturas se hicieron el 25 de septiembre de 2026 sobre el build de producción de la tienda, servido en local con una base de datos desechable y los diez productos del catálogo. Algunos estados se provocaron a propósito para poder enseñarlos: el producto agotado, el catálogo que tarda o falla, la categoría vacía y el carrito guardado con precios viejos. Lo que se ve en cada uno es el código de producción. Las fotografías de producto son las del proyecto original; las de ambiente de la portada y la historia se generaron para esta versión. Las pantallas con algún defecto visible se dejaron fuera.

15Aprendizajes

Un buen producto no necesita fingir más infraestructura de la que el negocio puede operar. Quitar cuentas, carrito en servidor y checkout hizo el sistema más pequeño, más seguro y más fácil de adoptar, y convirtió una limitación real en un flujo coherente. La versión que más aporta no fue la que más hacía, sino la que mejor se ajustaba a cómo vende el negocio.

16Estado actual

En línea en delicate.jonasjavier.dev desde el 25 de septiembre de 2026: un servicio Docker en Railway con PostgreSQL, un volumen para las fotos y dominio propio con HTTPS. El repositorio es público para evaluación, bajo licencia propietaria, con la integración continua en verde y 18 pruebas automatizadas que pasan. Antes de anunciarlo, quedan las validaciones que dependen del negocio y están en su lista de salida: políticas de entrega y privacidad, un pedido completo probado en Android e iPhone, copias de seguridad y monitoreo. No publico ventas ni visitas porque no las mido.

La siguiente línea del producto ya está especificada: un configurador guiado de jabón personalizado cuyo resultado es una solicitud por WhatsApp, no una compra automática. Todavía no forma parte del sistema.