Caso de estudio2026
Una librería con tres sedes, 3.538 productos y una caja que no podía parar.
Doce días de la primera línea al lanzamiento, sin migrar la operación. Santo & Seña estrenó un sitio que se parece a la casa, mientras WordPress siguió moviendo la tienda, la facturación y el punto de venta.
- Cliente
- Santo & Seña
- Ubicación
- Bogotá, Colombia
- En línea desde
- 10 de septiembre de 2026

(01) El encargo
Un sitio nuevo, sin tocar la operación.
Santo & Seña es una librería y tienda de discos en Bogotá, con tres sedes y un catálogo de 3.538 productos. Su operación (inventario, facturación, punto de venta) vivía sobre WordPress y WooCommerce, y funcionaba. Lo que no funcionaba era la cara: el sitio era el tema de WordPress de siempre, lento de cargar y ajeno a lo que la casa es.
El encargo no fue «rehagan la tienda». Fue más difícil: hacer un sitio nuevo sin tocar la operación. La caja no podía dejar de facturar un solo día, y las 6.115 direcciones que Google ya tenía indexadas no se podían perder.


(02) La restricción central
No había ventana de mantenimiento.
WordPress no se migró, no se apagó, no se congeló. Siguió siendo el motor. Encima se construyó un puente: el sitio nuevo sirve lo que sabe servir (el catálogo, las fichas, los eventos, el blog, el buscador) y lo que no sabe se lo pide a WordPress por detrás. El pago, la cuenta del cliente y el escritorio de administración siguen saliendo de WordPress, en el mismo dominio y sin una redirección visible.
- 01Lanzar sin riesgo de cajaEl día del cambio, la facturación siguió exactamente igual, porque nadie tocó el sistema que factura.
- 02Volver atrás en cinco minutosEl plan de reversa era un registro DNS con TTL de 300 segundos, con el alias y el CNAME anteriores anotados, con nombre y valor, junto al resto del lanzamiento.
- 03Conservar el SEOLas 6.115 direcciones vivas se honran con redirecciones 301 permanentes, que traspasan la autoridad de la página vieja a la nueva en vez de dejarlas compitiendo.
(03) Seis decisiones
Seis decisiones y lo que costaron.
Un caso de estudio sin contrapartidas es un folleto. Estas son las decisiones que más peso tienen, con lo que costaron.
- 01
La música se precomputa, no se resuelve en vivo
WooCommerce no sabe qué artista es cada disco. El cruce de cada producto contra Discogs, MusicBrainz e iTunes se hace de noche y se versiona en el repositorio. Costo: un archivo generado que Git no sabe fusionar. Resultado: 102 discos resueltos y 48 vinilos sonando en el tocadiscos del sitio.
- 02
El buscador corre en el navegador
Buscar en 3.538 productos en vivo era una petición por tecla contra un servidor compartido. El índice se genera al compilar. Costo: 830 KB que se descargan una vez, pesados contra un buscador que a veces no responde.
- 03
Analítica propia que no identifica a nadie
Un contador sobre Upstash Redis, sin cookies ni datos personales, y un panel privado. Sin embudos ni atribución, pero muestra lo que ninguna herramienta de terceros da: lo que la gente buscó y no encontró.
- 04
El iPad de la tienda es una pieza aparte
El iPad donde los clientes escuchan discos no es una pantalla más pequeña, es otro problema: sin enlaces, todo con el dedo, y se reinicia solo para el siguiente cliente. Costo: código duplicado a propósito.
- 05
Todo lo que rota, rota por el día y no al azar
Las categorías, las novedades, el disco del día y la sede destacada rotan por el número de día en Bogotá. Todo el mundo ve lo mismo el mismo día, y quien vuelve mañana encuentra otra cosa.
- 06
Tres tareas programadas, y una que puede fallar queriendo
Catálogo (diaria), reporte del mes (diaria) y salud (13 comprobaciones, ocho veces al día). Una cuarta termina en rojo a propósito cuando una lista escrita a mano apunta a algo agotado.





(04) Lo que salió mal
Tres semanas duras, documentadas con la medición que las cerró.
- 01El hosting confundió el tráfico propio con un ataqueLas fichas de producto empezaron a fallar, y el punto de venta también. Una ruta de diagnóstico temporal demostró que el bloqueo dependía de por dónde salía la petición; con ese dato, el proveedor encontró nuestras peticiones en sus registros y retiró la protección. Quedó una puerta directa para el equipo, una comprobación de salud más fina y un documento de una página.
- 02El presupuesto de red era mayor que el plazo de la funciónUna de cada veinticinco fichas fallaba en la primera visita, siempre a los quince segundos: el código daba veinte a cada consulta y la plataforma mataba la función a los quince. Arreglo: seis segundos por consulta y plazo de treinta en las rutas que más piden. Doce fichas frías al azar después: todas entre 0,17 y 1,87 segundos.
- 03La factura se duplicó, y el culpable no era el que parecíaLa optimización de imágenes eran 82 centavos de veintitrés dólares. El 88 % de la factura eran 117 envíos a producción en trece días, más la precarga de enlaces, que renderizaba la tienda sin caché una vez por cada opción de filtro. Ahora la precarga está apagada donde cuesta: la portada pasó de 35 precargas, 9 sin caché, a 24, ninguna sin caché.
- 04Tres regresiones, revertidas el mismo díaRecortar los anchos de imagen rompió páginas ya guardadas en los navegadores, medir sin cuidado tumbó la compilación dos veces y el guardián de publicación conservó una versión mala durante dos horas. La comprobación de salud ahora verifica las secciones de la portada, no solo que responda.
(05) El método
Un agente de IA dirigido, no automático.
De los 343 commits, 239 los escribió un agente de IA y 80 el estudio. Eso explica el ritmo, y también los límites. Cada decisión quedó documentada en el propio código, y cada diagnóstico se cerró midiendo, no opinando.
Lo que no funcionó: la verificación necesita la misma disciplina que el desarrollo. Y la dirección humana no es opcional: las decisiones que más valor tuvieron (no migrar, el puente, la analítica propia, el iPad como pieza aparte) salieron del negocio, no del código.
(06) Dónde está hoy
Dieciséis días en producción.
El catálogo de música se regenera cada noche, el informe del mes se arma solo, la portada se recompone con lo que va llegando a la tienda y la salud se comprueba ocho veces al día.
- 12Días del primer commit al lanzamiento
- 6.115Direcciones indexadas conservadas
- 13/13Comprobaciones de salud en verde
Las páginas responden en 0,18 a 0,66 segundos. Las fichas frías cargan en 0,17 a 1,87 segundos, sin caídas. En nueve páginas, 1.755 de 1.755 imágenes verificadas.

(07) Lo que sigue
El trabajo no está cerrado y el caso tampoco lo finge.
- 01Modo degradado del catálogoQue la tienda sirva los datos de ayer, con aviso, cuando el back-office no responda. Es la raíz de la mayoría de los incidentes de este periodo.
- 02Cachear la página de tiendaEs la única página de compra que se dibuja entera en cada visita.
- 03Convertir el dato en acciónEl panel ya muestra qué buscó la gente y no encontró, y qué dejó en el carrito sin pagar. Falta lo que sigue: una lista de correo propia y un aviso de «vuelve a estar disponible».
Front
Next.js 16, React 19, Tailwind CSS 4 y TypeScript sobre Vercel. Ocho dependencias directas: sin librería de componentes, gestor de estado ni ORM.
Back-office
WooCommerce sobre WordPress (Hostinger), sin migrar. Punto de venta: Pliego, plugin propio del cliente, facturando a Siigo.
Datos y automatización
Upstash Redis para sesiones y analítica. Discogs, MusicBrainz e iTunes para el catálogo. GitHub Actions para tres tareas programadas.
¿Tu operación funciona, pero tu sitio no se parece a ti?
Podemos construir la cara nueva sin tocar lo que sostiene el negocio. Eso es lo que hace Mattriz.
Cuéntanos tu proyecto