Retail y ecommerce

Sistemas de comercio construidos, migrados y mantenidos rápidos bajo carga.

Trabajamos sobre Adobe Commerce, VTEX y Shopify: tiendas nuevas, migraciones desde plataformas heredadas, y el tramo largo después del lanzamiento, que es cuando llega el tráfico de verdad.

Entre nuestros clientes

  • Lentesplus
  • KURU Footwear
  • TGI Fridays
  • AB InBev

Qué hicimos con tráfico real encima

Cuatro proyectos sobre sistemas que no se podían apagar mientras se trabajaba.

Qué cambia cuando ya está pasando dinero por ahí

Una tienda deja de ser un proyecto el día que toma su primer pedido. Todo lo de abajo aplica a un sistema que heredas, y también a uno que construiste tú mismo la semana siguiente al lanzamiento.

Preguntas que nos hacen antes de la primera llamada

  1. ¿Construyen tiendas desde cero o sólo trabajan sobre las que ya existen?

    Las dos cosas. Algunos clientes llegan sin operación de ecommerce y la construimos; más seguido el sistema ya existe y el trabajo es migrarlo, estabilizarlo o mantenerlo rápido mientras crece. Los casos publicados acá son todos del segundo tipo, lo que dice más sobre qué proyectos se convirtieron en casos que sobre qué hace el equipo.
  2. ¿Sobre qué plataformas trabajan de verdad?

    Adobe Commerce, VTEX y Shopify, las tres en las que el equipo tiene certificaciones. Nombrar una lista más larga sería nombrar plataformas que nunca tuvimos que arreglar a las tres de la mañana. Del lado de la tienda y de la app el trabajo es React y React Native.
  3. ¿Pueden migrar una tienda sin bajarla?

    Sí, y Lentesplus es el ejemplo publicado: una tienda de alto tráfico vendiendo en cuatro países se movió de Magento Open Source 1.9 a Adobe Commerce Cloud mientras seguía en uso activo, con requerimientos nuevos llegando todo el tiempo. Lo que eso cuesta es planificación y no caída de servicio: no hay una versión congelada desde la cual trabajar, así que la secuencia tiene que absorber una línea de base en movimiento.
  4. ¿Cómo es el trabajo continuo?

    Releases semanales y arreglos diarios, con prioridades puestas contra la facturación y no contra el orden del backlog. En KURU eso significó desarrolladores certificados trabajando part-time y publicando cada semana, en vez de un equipo grande publicando cada trimestre, empezando por los errores de checkout que costaban ventas todos los días.
  5. ¿Se ocupan de accesibilidad?

    Sí, y en TGI Fridays se auditó en vez de darse por sentada: herramientas automáticas más testing manual de cómo se movía la gente de verdad por el menú y el checkout, con HTML semántico y navegación por teclado dentro del design system, para que las marcas que vinieran después siguieran siendo accesibles por defecto.

Cuéntanos qué se está rompiendo mientras vende.

En una sesión de trabajo de 45 minutos repasamos qué está haciendo la tienda ahora, qué está costando y dónde, y cuál debería ser el orden de los arreglos. Trae el embudo del checkout.