La plantilla daba por hecho Stripe, dólares, inicio de sesión por email y servidores con acceso a GitHub. Una tienda iraní de moda masculina no podía contar con nada de eso.
El rol
Diseñador de producto y desarrollador de la tienda, las páginas de producto, el proceso de compra, los pagos, la cuenta del cliente, la administración y la infraestructura, con agentes de programación de IA que escribieron la mayor parte del código.
El resultado
En producción en faymen.ir desde julio de 2026 y cobrando pagos; un único informe de feedback destapó que 113 de 166 productos devolvían 404, ya corregido.
Figura 01
Figura 01En un móvil: la tienda, una página de producto y la cuenta del cliente. La pantalla de la cuenta procede de una compilación local del código de producción con datos de prueba.
01Contexto
Una sastrería construida sobre una plantilla de comercio
Fayman (فیمن) vende online moda masculina de sastrería: trajes, blazers, pantalones, camisas, zapatos y complementos, con una guía de tallas, una guía de tejidos y un servicio de confección a medida. La tienda arrancó el 23 de junio de 2026 a partir de la plantilla oficial de ecommerce de Payload, más una primera pasada de limpieza. El 15 de septiembre, 491 commits después, la mayor parte se había sustituido.
La plantilla ofrecía un catálogo, un carrito y un modelo de pedidos que funcionaban. También daba por hecho Stripe, dólares estadounidenses, cuentas con email y herramientas alojadas por terceros. El trabajo consistía en convertirla en una tienda que un cliente iraní pueda usar desde la primera búsqueda hasta una solicitud de devolución, y que el equipo de la tienda pueda gestionar sin un desarrollador.
De los 518 archivos de código fuente del final, 80 siguen igual que en la plantilla. Los pagos, el inicio de sesión, el proceso de compra y la moneda se sustituyeron por completo; la cuenta del cliente, las herramientas de administración y 17 de los 25 bloques de página son nuevos.
Figura 02Una página de categoría en escritorio: cuadrícula de derecha a izquierda, filtros a la derecha y precios en tomán con el precio anterior al descuento tachado.
Doce semanas, por fecha
01
Plantilla23 jun · La plantilla de ecommerce de Payload más una primera pasada de limpieza
02
Lo básico para Irán28 jun · Maquetación en persa de derecha a izquierda, precios en rial y un adaptador de pagos Shaparak
02Problema
Cinco supuestos que no se cumplen en Irán, y una tienda que gestionar
Cada supuesto de una plantilla de comercio internacional tuvo que sustituirse, no configurarse:
Pagos — Stripe no opera en Irán. Las tiendas cobran a través de las pasarelas de Shaparak, y cada pasarela tiene su propio protocolo.
Moneda — los precios se guardan en rial y se dicen en tomán. Una sola integración que invierta el factor de diez le cobra a un cliente diez veces de más o diez veces de menos.
Identidad — los clientes se identifican ante una tienda por su número de teléfono, no por una dirección de email, y el servidor de producción nunca tuvo un servicio de email.
Infraestructura — GitHub y Docker Hub no son accesibles de forma fiable desde un servidor iraní, así que un despliegue que dependa de ellos puede fallar justo cuando hace falta una corrección.
Tipografía — un lenguaje de diseño escrito para software en inglés, de izquierda a derecha, tenía que servir para el comercio minorista en persa.
Operaciones — el equipo de la tienda tenía que fijar descuentos, stock y páginas por su cuenta, en persa y con fechas del calendario persa.
03Mi rol
Un diseñador, muchos agentes
Diseñé el producto y dirigí su construcción. Los agentes de programación de IA escribieron la mayor parte del código a partir de especificaciones escritas; el alcance, la dirección de diseño y cada versión en producción los decidieron personas.
Responsable
↳Arquitectura de la información, flujos y el lenguaje de diseño
↳Tienda, página de producto, proceso de compra y la cuenta del cliente
↳Reglas comerciales: precios, descuentos, stock y pagos
↳Las herramientas de administración con las que funciona la tienda
↳Infraestructura dentro del país y el proceso de publicación
Corresponsable
—
Colaboración
↳Los comentarios de la tienda, gestionados con un gestor de tareas
↳Agentes de programación de IA, para la implementación
Cada comentario sin procesar se contrastaba con el código real antes de convertirse en una especificación que un agente pudiera construir sin hacer ninguna pregunta de seguimiento. Cada versión en producción queda anotada en un registro de despliegues de solo adición.
Cómo avanzaba una tarea
01
AvisoUn comentario sin procesar o una captura de pantalla entra en el gestor de tareas
02
InvestigarSe contrasta con el código real antes de construir nada
04Sistema
Lo que tenía que funcionar como un solo sistema
A una tienda de ropa se la juzga por el camino que va de una búsqueda a un pedido entregado, y por lo que ocurre cuando ese camino se rompe. Las partes de abajo comparten datos: la insignia de una tarjeta de producto, el filtro de rebajas de la tienda, el total del carrito y el importe enviado al banco salen de una misma regla de precios.
El diseño pasó por un ciclo de revisión propio: una captura de pantalla de un problema, un diagnóstico contrastado con el código y el lenguaje de diseño, una tarjeta y, después, la implementación. A 12 de septiembre había 63 tarjetas de diseño, 55 de ellas terminadas.
Un único resolvedor de precios alimenta la tarjeta de producto, el carrito, el desglose y la comprobación del pago, así que el precio que ve el cliente es el que se le pide al banco.
El sistema, por áreas
01
EscaparateLo que ve el cliente
Inicio y secciones de producto
Catálogo y filtros
Búsqueda
Página de producto
Guías de tallas y tejidos
Páginas de ayuda
02
CompraDel carrito a un pedido pagado
Carrito
Proceso de compra en una página
Acceso por teléfono
Direcciones guardadas
Pasarelas de pago
Monedero
Una compra, tal como la ejecuta el código
01
EncontrarSecciones de inicio, filtros de la tienda o búsqueda
02
DecidirPágina de producto, línea de stock, guías de tallas y tejidos
05Descubrimiento
Encontrar el producto adecuado
Los clientes llegan a un traje desde preguntas distintas: una ocasión, una categoría, unas rebajas, una búsqueda o un enlace compartido. La página de inicio responde a varias de ellas, y cada respuesta termina en la misma tienda.
Sus carruseles de productos salen de un solo bloque, Product Section, con cuatro orígenes: una regla por categoría con interruptores de solo rebajas y solo en stock, productos elegidos a mano, una URL de la tienda pegada o una lista de enlaces de producto. Tiene tres diseños: carrusel, cuadrícula y destacado. Cada origen pasa por la misma consulta que usa la tienda, así que un carrusel y la tienda no pueden discrepar sobre qué está rebajado o en stock. Los editores lo usan hoy en la página de inicio en producción para carruseles como conjuntos completos rebajados y tallas sueltas.
La fila de ocasiones está encima de la fila de categorías, siguiendo los comentarios de la tienda: un cliente empieza por “tengo una boda”, no por “quiero un blazer”. En la tienda, todos los filtros viven en la URL: tejido, ocasión, estilo, un rango de precios en tomán, solo en stock y solo rebajados. El stock, la rebaja y el precio se comprueban sobre la misma talla, así que una talla agotada en rebajas no puede colar un producto en los resultados. En un móvil, los filtros se abren en un panel, y los filtros activos siguen visibles como chips que se pueden quitar.
La búsqueda es el punto de entrada más débil. Solo busca en los títulos de los productos y todavía no trata como iguales las formas árabes y persas de las letras. El lookbook es editorial: sus looks llevan a páginas de la tienda filtradas, no a productos concretos.
Figura 03El bloque Product Section en la página de muestra de la tienda, que recoge 60 combinaciones de origen, diseño y forma de mostrar el precio. Cada carrusel indica su origen y cómo muestra los precios.
Los filtros se abren en un panel.
06Página de producto
Reducir la incertidumbre antes de la compra
Comprar ropa de sastrería online plantea tres preguntas: si quedará bien, de qué está hecha y qué pasa si no es lo que se esperaba. La página de producto se rehízo en torno a ellas: una columna de compra que permanece junto a la galería, una línea de stock, una fila de confianza con las condiciones de entrega y de devolución en 7 días, un acordeón con talla, cuidados y envío, y una barra de compra que en un móvil siempre queda al alcance.
Las tallas tenían que decir la verdad. El 13 de agosto, 23 de los 25 productos con tallas ofrecían al menos una talla sin nada detrás que se pudiera vender. Ahora una regla compartida oculta las tallas en las que un producto no se fabrica, desactiva las agotadas y etiqueta como «ناموجود» un producto al que no le queda nada. Por debajo de diez unidades, la página indica cuántas quedan.
El Size Finder de la guía de tallas pide la prenda, un ajuste preferido y las medidas corporales, y responde a partir de las tablas de tallas de la tienda. Entre dos tallas elige la mayor, porque estrechar es más seguro que ensanchar. Fuera de rango ofrece una consulta de medidas, y para las camisas da una medida de cuello en lugar de adivinar una talla por letras. La guía de tejidos relaciona cada tela con la estación y el uso, y cada tejido enlaza a la tienda filtrada por él.
Hay dos partes sin terminar. El Size Finder no está en la página de producto y no lee lo que vende realmente cada producto, y la página de producto no muestra el tejido de cada producto.
Compilación local, datos de prueba: una talla agotada y desactivada, una talla elegida, el stock confirmado y las condiciones junto al botón.
La tienda en producción: un producto rebajado con su precio anterior tachado.
Figura 05La página de producto en un móvil. La barra de compra de abajo sigue al alcance mientras se desplaza la página.
El Size Finder: prenda, ajuste y medidas, y después una talla.
Envíos: métodos, plazos y el umbral de envío gratuito.
07Proceso de compra
Del carrito a un pedido pagado
El precio del carrito se calcula en el servidor con el mismo resolvedor que usa la comprobación del pago, así que el carrito y el banco no pueden discrepar. Al abrir el carrito, sus precios se recalculan con el catálogo en vivo: en producción, 4 de 15 carritos abiertos tenían un total desactualizado. El desglose muestra el precio de lista, los descuentos de producto y el cupón en líneas separadas.
El proceso de compra ocupa una sola página. En un móvil, el resumen del pedido va primero. Un cliente sin sesión iniciada entra con un número de móvil y un código de seis dígitos sin salir de la página, y un número nuevo obtiene una cuenta. Se selecciona la primera dirección guardada. Solo se muestran los métodos de pago para los que el pedido cumple los requisitos, y el botón indica el importe: «پرداخت … تومان». Todo lo que aún no se puede usar se explica en una frase en lugar de mostrarse como un control en gris, por ejemplo un saldo del monedero al que le falta una cantidad concreta.
El pago pasa por un único adaptador para todas las pasarelas iraníes: Zarinpal, Zibal, Torob Pay, SnappPay y DigiPay, además del monedero de la tienda. Antes de enviar a nadie a un banco, el servidor vuelve a calcular el total y se niega a cobrar si no coincide con el carrito hasta el último rial. El pedido se crea solo después de que la pasarela confirme el pago. Una llamada de retorno repetida no puede crear un segundo pedido, y una tarea que se ejecuta cada diez minutos recoge los pagos cuya llamada de retorno nunca llegó.
La forma del adaptador viene de fallos reales. En dos días de septiembre, DigiPay necesitó siete correcciones: un ajuste de endpoint vacío que rompía el proceso de compra, un formato de petición que hacía parecer inválidas unas credenciales válidas, un retorno desde la pasarela que llegaba a una ruta inexistente y una unidad de importe que hubo que confirmar como rial con un pago real. Cada una se convirtió en una regla: el endpoint de DigiPay es un ajuste obligatorio y, si está vacío, la pasarela se oculta; todas las pasarelas aceptan los dos tipos de petición de retorno, y nunca se da por supuesta la unidad de un importe.
El carrito: precio de lista, descuento del producto y un cupón en líneas separadas.
08Decisiones clave
Seis sustituciones, no configuraciones
Cada una cambia un valor por defecto de la plantilla por la restricción que ignoraba.
01
Guardar rial entero, mostrar tomán
Los precios se dicen en tomán pero se liquidan en rial. Cada importe se guarda como rial entero y se convierte en un solo sitio para mostrarlo, así que un error de un factor de diez no puede llegar a un cobro.
Alternativas
Guardar tomán y convertir en cada pasarela
Compromiso
Cada integración declara su unidad en una sola frontera: las etiquetas de precio de Torob piden tomán; las pasarelas, rial.
02
Hacer del número de teléfono la única identidad
El inicio de sesión, el registro y el proceso de compra piden un número de móvil y un código de un solo uso. Las páginas de email y contraseña se retiraron: ninguna podía funcionar sin un servicio de email, y producción nunca lo tuvo.
Alternativas
Mantener el inicio de sesión por email junto al código
Compromiso
Cada inicio de sesión depende de la entrega de SMS, así que las solicitudes tienen un límite de frecuencia y un máximo diario.
Evidencia
La página de inicio de sesión en producción: un campo, un número de móvil y un botón que solicita un código.
09Cuenta
La cuenta, después de los pedidos y entre uno y otro
Un cliente que vuelve entra con el mismo número de teléfono y llega a un panel construido en torno a aquello por lo que la gente vuelve: pedidos en curso, el saldo del monedero, los productos guardados, las devoluciones abiertas y los tres últimos pedidos. La página anterior era un formulario de ajustes, con el estado de los pedidos en el tercer bloque de la página.
La lista de pedidos filtra por estado y muestra miniaturas de los productos, porque los clientes reconocen un pedido por lo que contiene. La página del pedido muestra un seguimiento en tres etapas (realizado, en proceso, completado), los precios pagados en su momento, la dirección y un botón de devolución durante siete días. Muestra solo lo que los datos permiten: el seguimiento no tiene fechas para las etapas posteriores, porque el sistema no registra cuándo se produjo cada cambio.
En una solicitud de devolución se eligen artículos, cantidades y un motivo, y el servidor comprueba el titular, el plazo de siete días y lo que ya se había devuelto. El equipo va cambiando el estado de la solicitud. Ningún dinero se mueve automáticamente; el equipo puede añadir el reembolso al monedero del cliente a mano. La página del monedero responde a “¿por qué mi saldo es este?” con un extracto en el que cada movimiento tiene un motivo, un enlace a su pedido y el saldo resultante. No hay botón de recarga, porque la recarga no existe y un botón la prometería.
Las direcciones guardadas aquí son los mismos registros que usa el proceso de compra. La lista de deseos guarda productos para los clientes con sesión iniciada. Los ajustes guardan un nombre y muestran el teléfono verificado, que no se puede cambiar ahí. Las preferencias de notificación se guardan, pero todavía nada envía mensajes a partir de ellas: aparte de los códigos de inicio de sesión, los clientes no reciben ningún SMS.
La cuenta, por áreas
01
Inicio de sesiónUn mismo flujo para clientes nuevos y habituales
Número de móvil
Código de seis dígitos
Sesión de 14 días
Cerrar sesión
02
PanelAquello por lo que la gente vuelve
Pedidos en curso
Saldo del monedero
Recuento de la lista de deseos
Devoluciones abiertas
Tres últimos pedidos
03
PedidosSolo los crea un pago confirmado
El panel: pedidos en curso, monedero, lista de deseos, devoluciones abiertas y pedidos recientes.
10Reglas comerciales
Las reglas detrás de la interfaz
Los descuentos tienen dos capas. Un producto o una categoría pueden llevar un descuento con fechas de inicio y fin fijadas en calendario persa; manda el descuento propio del producto, y los dos nunca se acumulan. Después, un cupón se aplica una vez por carrito, sobre el total ya rebajado, y solo cuenta como usado tras un pago confirmado. La insignia de ٪, el precio tachado, el filtro de rebajas de la tienda y los carruseles de rebajas leen la misma regla.
Ese orden se aprendió de una cesta real. Durante seis días de agosto, los cupones se aplicaron sobre el precio de lista y sustituyeron al descuento del producto, lo que cobraba de más a los clientes; un cupón débil podía incluso subir el precio. Ahora los cupones se aplican después de los descuentos del catálogo.
El stock se lleva por talla. Se comprueba cuando empieza el pago y se descuenta solo después de que el banco confirme, en una única actualización protegida, así que dos compradores de la última unidad no pueden completar ambos la compra. Si el stock se agota entre un momento y otro, el pedido se marca como reembolsado, se intenta revertir el pago y se devuelve el stock que ya se hubiera descontado para ese pedido.
El equipo lo gestiona desde una consola de descuentos que muestra cada descuento como activo, programado, caducado, desactivado o agotado, y desde un generador que crea códigos de un solo uso para una campaña.
Figura 11La consola de descuentos en la administración (compilación local, datos de prueba): productos y categorías rebajados, códigos de cupón y lo que está a punto de empezar o terminar.
11Operaciones
Gestionar la tienda sin un desarrollador
La administración está en persa por defecto, porque el equipo está en Irán, y las fechas de los descuentos se eligen en un calendario persa. Las páginas se construyen con bloques: la plantilla tenía 8, la tienda tiene 25 y 17 son nuevos, desde Product Section hasta la guía de tallas, las preguntas frecuentes y la política de devoluciones. Los enlaces de la cabecera, las columnas del pie de página, los enlaces a redes sociales y el orden de las categorías se editan en la administración.
Las herramientas de gestión se crearon para tareas que el equipo realmente hace. Los pedidos pagados esperan la confirmación de un operador y siguen marcados en rojo hasta que alguien los confirma. Una pantalla de tallas y stock muestra el stock por talla en cada categoría y avisa antes de eliminar una talla que todavía usan pedidos. El crédito del monedero se escribe en rial y aparece con palabras en tomán bajo el campo, porque un crédito no se puede deshacer.
Los SMS cubren tres eventos: el código de inicio de sesión, un aviso de venta al equipo y los nuevos contactos de ventas corporativas. Cada uno tiene una plantilla editable y sus propios destinatarios. La página de ventas corporativas recoge como contactos las consultas de 50 piezas o más; no hay precios por volumen ni sistema de presupuestos.
Quedan dos limitaciones: hay un único rol de administración, sin una cuenta de personal con permisos más reducidos, y las tablas de tallas en las que se basa el Size Finder están en el código.
12Hecho para Irán
Diseñar para Irán, no traducir para Irán
El diseño de derecha a izquierda fue más allá del atributo de dirección. La maquetación pasó a propiedades lógicas, que la plantilla no usaba en absoluto; los carruseles y las galerías siguen también el sentido de lectura con el teclado, y los números de teléfono, los códigos postales y los códigos de cupón van en campos de izquierda a derecha dentro de formularios en persa. Los precios usan cifras persas, y las fechas usan el calendario persa mediante el soporte de calendarios del propio navegador, no una librería.
El lenguaje de diseño se adaptó, no se inventó. Una capa de adaptación sobre un sistema existente, escrito para software en inglés, señala dónde discrepa de una tienda persa de moda masculina y establece que la adaptación prevalece. Su regla más tajante es un espaciado entre letras de cero en persa, porque el espaciado rompe las letras unidas. Las fuentes están alojadas en el propio servidor, así que la tienda nunca queda a la espera de Google.
El dinero sigue las reglas locales: se guarda en rial entero, se muestra en tomán, y las etiquetas de precio de Torob van en tomán para que el comparador de precios muestre la cifra correcta. El pie de página lleva el sello E-namad, en el que los clientes pueden hacer clic para llegar al registro de comercio electrónico de Irán. El 27 de septiembre, la configuración pública del proceso de compra de la tienda incluía Zibal, el monedero, Torob Pay y DigiPay.
La infraestructura se queda en el país: el código y las imágenes en un servidor Git autoalojado, los archivos multimedia en el almacenamiento de ArvanCloud, los despliegues con Coolify y la analítica en un Umami autoalojado. Las notas de arquitectura lo dicen sin rodeos: todo aquello de lo que depende el sitio en producción durante la compilación y el despliegue tiene que ser accesible dentro del país.
Es el único punto de esta lista que produce cifras erróneas con total aplomo, en lugar de cifras que faltan.
13Fiabilidad
Mantener en marcha una tienda en producción
El 10 de agosto, la tienda avisó de un producto que devolvía 404 aunque seguía apareciendo en la administración. Un barrido de solo lectura en producción mostró la escala real: 113 de 166 productos publicados eran inaccesibles. Había dos bugs superpuestos. La función de slug por defecto de Payload eliminaba todas las letras persas, y Next.js pasaba a las páginas sus slugs persas todavía con codificación porcentual, así que incluso un slug correcto fallaba. Primero se corrigió el código, después se repararon los 113 slugs en producción, y un segundo barrido devolvió 200 para los 166.
Cada versión pasa por un único control local: se comprueban los tipos generados y los import maps, y después vienen la comprobación de tipos, el lint, los tests y una compilación de producción. La batería tenía unos 1.086 tests el 1 de septiembre, 772 de ellos unitarios, y 1.354 a 12 de septiembre. Cada versión en producción queda anotada en un registro de despliegues de solo adición. Después, un script de smoke test comprueba la ruta de retorno de cada pasarela, la analítica y la tienda, y cada comprobación que contiene existe porque ese fallo llegó una vez a producción.
Un barrido de dependencias el 1 de septiembre actualizó 54 de 58 paquetes desactualizados, en dos lotes verificados más nueve actualizaciones mayores por separado, y dejó constancia de por qué se retuvieron los otros cuatro. Nunca se midieron cifras de velocidad de página, así que aquí no se afirma ninguna; el único cambio medido en la compilación es el del paso de compilación, de 88 a 18,2 segundos.
La corrección del 404, paso a paso
01
AvisoUn producto devuelve 404 pero aparece en la administración
02
Barrido113 de 166 productos publicados, inaccesibles
…no habría cambiado nada de lo que ve un cliente, porque un slug persa correcto seguía dando 404.
14Resultados
En producción, con las carencias a la vista
En producción en faymen.ir desde el 7 de julio de 2026 y cobrando pagos. No se publican cifras comerciales. Los números de abajo son correcciones medidas; el resto es alcance entregado.
Productos que devolvían 404, detectados y corregidos
113 / 166
Los títulos en persa producían slugs rotos; más de dos tercios del catálogo eran inaccesibles.
Resultado medido · Tarjeta de feedback y barrido en producción, 11 de agosto de 2026
Productos con tallas que ofrecían una talla que nadie podía comprar
23 / 25
Sustituido por una regla que oculta o desactiva tallas según lo que hay en stock.
Resultado medido · Tarjeta del sistema de tallas, 13 de agosto de 2026
Carritos abiertos con un total desactualizado
4 / 15
Ahora el carrito vuelve a calcular sus precios al abrirse.
Resultado medido · Nota en el código sobre la reparación del carrito
Una tienda que los clientes pueden usar de principio a fin
Tienda, proceso de compra, cuenta y administración: 491 commits en doce semanas, de la plantilla al proceso de compra centrado en el teléfono.
Entregable
Qué se entregó
↳Inicio de sesión solo por teléfono
Proceso de compra en una página
15Lo que aprendí
Lo que enseñó la tienda
01
Las restricciones que parecen trámites son decisiones de producto
“Docker Hub no es accesible” decide si una corrección se puede publicar durante unas rebajas; “no hay servicio de email” reescribió la identidad, el proceso de compra y el boletín.
02
Un aviso no es una tarea hasta que se contrasta con el código
Un aviso sobre un producto que devolvía 404 aunque seguía visible en la administración resultó ser, una vez contrastado con el código y el catálogo, dos tercios de la tienda y dos bugs distintos.
03
Mostrar solo lo que los datos pueden respaldar
El seguimiento del pedido no tiene fechas porque no se registra ninguna; un contador que no carga muestra un guion, no un cero; el monedero no tiene botón de recarga; el Size Finder no propone una talla que la tienda no pueda vender.
04
Dejar por escrito dónde discrepa un lenguaje de diseño prestado
Adaptar un lenguaje de diseño existente costó menos que escribir uno nuevo, y las discrepancias, como el espaciado entre letras en persa y la ausencia de ilustraciones, se convirtieron en su parte más útil.
En producción7 jul · faymen.ir servido desde un servidor dentro del país
04
Acceso por teléfono24 jul · Inicio de sesión con código por SMS junto al antiguo formulario de email
05
Oleadas de feedback10–31 ago · Comentarios de la tienda y revisiones de diseño: slugs, tallas, descuentos, proceso de compra
06
Monedero y cuenta2 sep · Crédito en tienda, el panel de la cuenta y las etiquetas de precio de Torob
07
Primero el teléfono15 sep · Todos los recorridos de la tienda que usaban email, sustituidos por el número de móvil
03
Tarjeta de especificaciónCriterios de aceptación a partir de los que un agente puede construir
04
ImplementarUn agente lo implementa en su propia rama
05
Control y publicaciónComprobación de tipos, tests y una compilación, y después un despliegue anotado en el registro
vuelve a 01 · Aviso
↺vuelve a 01 · Aviso
03
CuentaDespués de los pedidos y entre uno y otro
Panel
Pedidos
Devoluciones
Extracto del monedero
Lista de deseos
Ajustes
04
Reglas comercialesLo que lee la interfaz
Precios en rial
Descuentos de producto y categoría
Códigos de cupón
Stock por talla
Registros de pedidos
Libro de movimientos del monedero
05
OperacionesLo que gestiona el equipo de la tienda
Administración en persa
Bloques de página
Consola de descuentos
Pantalla de tallas y stock
Confirmación de pedidos
Ajustes de SMS
06
InfraestructuraDentro del país
Almacenamiento de ArvanCloud
Git autoalojado
Coolify
Analítica con Umami
Registro de despliegues
03
Elegir tallaLas tallas que no se fabrican, ocultas; las agotadas, desactivadas
04
CarritoPrecio calculado en el servidor y recalculado al abrirlo
05
Iniciar sesiónNúmero de móvil y un código de seis dígitos, dentro del proceso de compra
06
Dirección y métodoUna dirección guardada; los métodos para los que el pedido cumple los requisitos
07
PagarEn la pasarela; el pedido solo existe cuando el banco confirma
08
CuentaPágina del pedido, solicitud de devolución, monedero
Un filtro de ocasión activo queda como un chip que se puede quitar, con un contador en el botón.
Los resultados de búsqueda son la tienda, filtrada por la consulta.
Figura 04Filtros, un filtro activo y la búsqueda en un móvil. El estado vive en la URL, así que cualquier vista se puede compartir o recargar.
La guía de tejidos: qué tela va con cada estación, uso y cuidado.
Figura 06Las guías responden a las dudas de talla y tejido sin salir de la tienda, y llevan de vuelta al catálogo.
Las preguntas frecuentes, agrupadas por temas y con búsqueda en persa.
Figura 07Las páginas de ayuda responden a las preguntas que frenan una compra: talla, entrega, devoluciones y pago. El umbral de envío gratuito es un texto; el proceso de compra no calcula ningún coste de envío.
Sin sesión iniciada: primero el resumen y después el inicio de sesión con el número de móvil.
El código de seis dígitos. No hace falta tener una cuenta de antemano.
Con sesión iniciada: una dirección guardada, los métodos, lo que falta en el monedero explicado con palabras y el importe en el botón.
Figura 08El proceso de compra en un móvil, desde una compilación local del código de producción con datos de prueba. Una pasarela de prueba hace las veces del banco, y el número de teléfono está oculto.
03
Crear el pedido solo cuando el banco confirma
La plantilla confirmaba los pedidos desde el navegador. Aquí el servidor verifica el pago con la pasarela, importe incluido, y solo entonces crea el pedido y descuenta el stock.
Alternativas
Crear el pedido cuando se envía al cliente al banco
Compromiso
Si la comprobación de la pasarela agota el tiempo de espera, el cliente ve la página de error aunque el dinero se haya cobrado. La tarea de cada diez minutos crea el pedido más tarde, pero al cliente no se le avisa.
04
Tratar el crédito en tienda como un método de pago
El monedero se conecta al mismo adaptador que las pasarelas, así que tiene la misma comprobación del total, la misma protección contra duplicados y la misma tarea de recuperación. Su libro de movimientos es de solo adición: nadie, tampoco los administradores, puede editar ni eliminar un movimiento.
Alternativas
Una línea de saldo restada del total
Compromiso
En esta versión, el monedero tiene que cubrir el pedido completo; pagar una parte con el monedero y otra con tarjeta queda para más adelante.
05
Separar la confirmación del pedido de su estado
El equipo confirma cada pedido pagado en la administración. Es un indicador aparte con un botón de confirmar, no un quinto estado, porque el estado se muestra a los clientes y los pasos internos no deberían llegarles.
Alternativas
Añadir un estado “confirmado”
Compromiso
El equipo lee dos campos, así que los pedidos sin confirmar se señalan en la lista, en el menú y en el panel.
06
Mantener dentro del país todas las dependencias del despliegue
El código, las imágenes de contenedor, el almacenamiento multimedia, los despliegues y la analítica funcionan en Irán, así que una corrección se puede publicar aunque GitHub o Docker Hub no sean accesibles.
Alternativas
CI alojado por terceros y registros públicos
Compromiso
Más infraestructura que mantener, vigilar y respaldar.
Filtro por estado
Página del pedido
Seguimiento en tres etapas
Precios de compra
Botón de devolución durante 7 días
04
DevolucionesSolicitudes; el equipo fija el estado
Formulario de solicitud
Comprobaciones en el servidor
Lista de estados
05
MonederoUn libro de movimientos de solo adición
Saldo
Extracto con motivos
Paga pedidos completos
06
Datos guardadosCompartidos con el proceso de compra
Direcciones
Lista de deseos
Nombre y teléfono verificado
Preferencias de notificación (solo se guardan)
Figura 09Todas las páginas de la cuenta en un móvil, desde una compilación local del código de producción con datos de prueba. Abre una página para verla entera. Los números de teléfono están ocultos.
El extracto del monedero: un crédito de regalo, un pedido pagado con el monedero y un reembolso por una devolución.
Figura 10La misma cuenta en escritorio, con el menú de la cuenta junto a cada página (compilación local, datos de prueba).
Figura 12La administración, desde una compilación local del código de producción con datos de prueba: el aviso de pedidos sin confirmar, la lista de pedidos, el botón de confirmar, la pantalla de tallas y stock y un crédito del monedero escrito en tomán.
03
Dos causasLos slugs perdían sus letras persas; las páginas recibían slugs codificados
04
Corregir y repararPrimero el código, después 113 slugs reescritos en producción
