Una tienda sin reputación
que igual da confianza

01

El problema

Diseñar una tienda que nadie conoce, para que un desconocido le deje los datos de su tarjeta.

Una marca con años encima puede permitirse fricción: la gente ya sabe que el producto llega. Una tienda nueva no tiene ese crédito. Todo lo que en un sitio conocido es un detalle —un plazo vago, un costo que aparece tarde, una foto que no coincide con lo que dice el texto— en una tienda nueva es motivo suficiente para cerrar la pestaña.

En dropshipping el problema se agrava: los plazos son largos, el vendedor no tiene el producto en la mano y el comprador lo intuye. Así que el proyecto no se planteó como «hacer una tienda linda» sino como una pregunta más concreta: qué tiene que pasar en cada pantalla para que alguien que llegó hace treinta segundos decida confiar.

La respuesta que guía todo el sitio es una sola: adelantar la información incómoda. El costo del envío, el plazo real, qué pasa si no llega, cómo se devuelve. Todo lo que una tienda suele esconder hasta el último paso, acá está antes de que lo pregunten.

02

Tres decisiones difíciles

Difíciles porque en las tres la opción correcta cuesta algo. Van con su contra, porque una decisión sin costo no era una decisión.

03

El sistema

Nada se decide dos veces. Un color, una medida y una regla viven en un solo lugar y el resto del sitio los consulta.

El color, la tipografía, el espaciado y los radios son variables de CSS. Cambiar el fondo del sitio entero fue editar una línea. Cuando el alto del logo tenía que igualar al del buscador, no se sincronizaron dos números: se creó uno solo que usan los dos.

Lo mismo con las reglas de negocio. Si un producto está agotado, si le quedan últimas unidades, cuánto se ahorra y si supera el umbral de envío gratis de $ 100.000 son funciones que viven junto a los tipos de datos. Ninguna vista las reimplementa, así que ninguna puede contradecir a otra.

El catálogo se valida al construir el sitio: si un producto sale sin precio, sin foto o con un descuento imposible, la compilación falla y dice cuál. Con 17 productos y dieciocho campos cada uno, ese aviso es la diferencia entre encontrar el error ahora o descubrirlo en producción.

04

Alternativas descartadas

Casi todas eran defendibles. Lo que las descartó fue el tamaño real de este proyecto, no una preferencia.

• React con renderizado en el servidor → Astro estático

  Un catálogo que no cambia entre visitas no necesita un servidor pensando en cada pedido. Astro entrega HTML terminado y manda al navegador sólo el JavaScript del carrito y los filtros. La consecuencia se mide: 0 ms de bloqueo del hilo principal en las cuatro pantallas.

• Un servicio de búsqueda externo → Índice en el navegador, 18 KB

  Con 36 productos, contratar un servicio significaba una dependencia, una clave y una ida y vuelta a la red para resolver algo que entra en el HTML. Las sugerencias aparecen mientras se escribe, sin una sola petición. Está anotado dónde deja de servir: a partir de unos cientos de productos, el peso del índice manda.

• Filtrar en el servidor → Filtrar en el navegador sobre HTML completo

  El listado llega con los 36 productos renderizados, así que el buscador de Google los indexa todos y filtrar no cuesta un viaje. El mismo límite que la búsqueda, y por la misma razón.

• Modal al agregar al carrito → Panel lateral con barra de envío gratis

  Un modal interrumpe y obliga a decidir «seguir o pagar». El panel lateral confirma que se agregó, muestra cuánto falta para el envío gratis y se cierra solo con Escape, sin bloquear el catálogo que la persona estaba mirando.

• Registro obligatorio antes de pagar → Compra como invitado

  Es de los mayores destructores de conversión que existen, y este sitio no necesita cuentas para entregar un pedido. Se piden los datos que hacen falta para facturar y avisar, y cada campo dice para qué se pide.

05

Resultados verificables

Todos salen de una medición que se repite con un comando. No hay métricas de negocio: este proyecto no tuvo clientes, y una conversión inventada no prueba nada.

• 100 Accesibilidad Lighthouse, en 3 de 4 pantallas
• 100 Buenas prácticas Lighthouse, en las 4
• 0 ms Bloqueo del hilo TBT en las 4 pantallas
• 0 Infracciones de axe sobre las 64 páginas
• 32/32 Contraste combinaciones reales, fórmula WCAG
• 33 KB Peso de la página más grande comprimida, meta < 300 KB
• completo Circuito de compra con teclado verificado paso por paso
• 2,1 – 4,4 s LCP móvil meta < 2 s · fotos provisorias de terceros

06

Qué haría distinto

Cuatro cosas, y las cuatro se aprendieron rompiendo algo.

1. Las fotos propias, desde el primer día

   Es lo único que impide llegar a la meta de velocidad. Las imágenes son placeholders servidos por un tercero: antes de pedir el primer byte hay que negociar una conexión con otro dominio. Ninguna optimización del código compensa eso. Empezar por las fotos habría cambiado el número final.

2. Definir antes qué vive en el sistema y qué en la página

   Astro aísla el CSS por archivo. Tres errores distintos salieron de lo mismo: estilos escritos dentro de una página que otra página necesitaba, y reglas que no alcanzaban a los elementos creados por JavaScript. Ninguno era difícil de arreglar; todos fueron difíciles de encontrar.

3. Auditar la salida compilada, no el código

   Dos de los errores más caros sólo existían después del compilador: el minificador borraba una propiedad del efecto de vidrio, y el generador de la vista previa partía un guion al medio. Mirando el código fuente los dos eran invisibles. Todas las pruebas de este proyecto corren sobre lo que recibe el navegador.

4. Escribir las pruebas mientras se construye

   Aparecieron cuando algo ya se había roto dos veces. Cada una encontró después un defecto que yo no estaba buscando — el orden de encabezados, el voseo que sobrevivió al barrido, el desborde de diecinueve píxeles en móvil. Escritas antes, habrían atajado los tres.