Que te bloqueen en la ejecución 47 a las 3 de la mañana es lo que mata tu pipeline. No un selector roto. No una página que cambió de markup.

Nadie fracasa en web scraping porque su `document.querySelector` estuviera mal escrito. Fracasan porque el sitio objetivo detecta tu fingerprint TLS en el request 43, te sirve un 403 y tu script en bucle reintenta hasta que el VPS se queda sin memoria.

*Apify no es una empresa de scraping. Es una empresa de anti-fragilidad.* Esa distinción es toda la lección.

Y aquí está la parte que ningún tutorial te cuenta: el código de scraping — lo que todo el mundo comenta — te lo regalan gratis. Es open source. Lo que pagas es la fontanería: rotación de proxies, reintentos, escalado serverless, almacenamiento y el hecho de que tu scraper siga vivo mañana.

Vamos a construir algo real. Pero primero, derribemos la suposición equivocada.

---

El Problema: Crees que el Scraping es un Problema de Código

Hay dos mentiras circulando por ahí sobre web scraping en 2026.

La primera dice que scraping está muriendo porque la IA "ya lo sabe todo". Falso. La adopción de LLMs ha *aumentado* la demanda de datos frescos y estructurados para RAG pipelines y conjuntos de evaluación. Un modelo fundacional no puede saber el precio actual de un producto ni el estado de una oferta. Eso solo lo da un scraper que corre hoy.

La segunda mentira dice que scraping es trivial: un bucle `for` sobre URLs con una librería de selectores.

Eso funciona exactamente hasta la primera página que te bloquea.

El cuello de botella se desplazó. Ya no es "conseguir el HTML". Es mantener el pipeline vivo a escala contra defensas anti-bot que fingerprintean tu TLS, throttlean tu concurrencia y te sirven honeypots que parecen datos reales.

El código nunca fue el problema. *La resiliencia es el problema.* Y esa es exactamente el área que Apify construyó alrededor de un core open source llamado Crawlee.

---

La Evidencia: el Scraper que Gana Nunca se Ejecuta en tu Portátil

Miremos el boilerplate. Un scraper ingenuo con `axios` + `cheerio`:

```javascript

// scraper_naive.js — muere en el primer 403

const axios = require('axios');

const cheerio = require('cheerio');

const urls = ['https://ejemplo.com/a', 'https://ejemplo.com/b'];

for (const url of urls) {

const { data } = await axios.get(url); // → 403 en producción, sin reintento

const $ = cheerio.load(data);

const titulo = $('h1').text();

console.log(titulo);

}

```

Cinco líneas. Funciona en local. Y se rompe en producción cuando el sitio detecta que no hay sesión, que no hay headers reales de navegador, que el ritmo de requests es de bot.

Ahora el mismo objetivo con Crawlee en Node:

```javascript

// crawlee_scraper.js — sobrevive a producción

import { CheerioCrawler } from 'crawlee';

const crawler = new CheerioCrawler({

maxRequestsPerCrawl: 100,

maxConcurrency: 10,

// Session pool: rotación de identidad + reintentos automáticos

useSessionPool: true,

sessionPoolOptions: {

maxPoolSize: 50,

blockedStatusCodes: [403, 429], // detecta bloqueo → gira sesión

},

requestHandler: async ({ request, $ }) => {

await crawler.pushData({

url: request.url,

titulo: $('h1').text().trim(),

fecha: $('time').attr('datetime'),

});

},

});

await crawler.run(['https://ejemplo.com/listado']);

```

La diferencia no son los selectores. Son ~15 líneas de configuración que gestionan reintentos, detección de bloqueo y salida estructurada a dataset.

*Eso es el valor de Crawlee: no es lo que raspa. Es lo que ya no tienes que escribir tú.*

El mismo patrón existe en Python. Para objetivos con mucho JavaScript, usas el `PlaywrightCrawler`, que levanta un navegador headless con un session pool consolidado. Intentar eso a mano — con Playwright crudo y lógica manual de waits — es semanas de debugging que nadie te agradece.

Y aquí está la decisión estratégica que casi nadie analiza: Apify renombró su SDK a Crawlee en 2022 y lo liberó como open source con un nombre neutral. No es caridad. Es que el foso no está en el código — que cualquiera puede forkear — sino en la capa de operación: inventario de proxies, uptime, scheduling, almacenamiento y tooling de compliance.

Regalaron el cebo. Venden la fontanería.

---

El Análisis: el Modelo de Actors es Serverless con Entrada y Salida Tipadas

Aquí es donde el tutorial se separa del chiste. Porque un "Actor" en Apify no es "código subido a la nube". Es un cambio de mentalidad:

*Un scraper deja de ser un script y se convierte en un microservicio serverless con contrato de entrada, contrato de salida y ciclo de vida.*

Envolver tu crawler con el patrón Actor:

```javascript

// main.js — el mismo código corre en local y en la nube

import { Actor } from 'apify';

import { CheerioCrawler } from 'crawlee';

await Actor.main(async () => {

const input = await Actor.getInput(); // viene del INPUT_SCHEMA

const { urls, maxItems } = input;

const crawler = new CheerioCrawler({

maxRequestsPerCrawl: maxItems,

requestHandler: async ({ request, $ }) => {

await Actor.pushData({

url: request.url,

titulo: $('h1').text().trim(),

});

},

});

await crawler.run(urls);

console.log('Actor completado.');

});

```

Con un `INPUT_SCHEMA.json` que declara qué acepta tu Actor:

```json

{

"title": "Raspador de ejemplo",

"type": "object",

"properties": {

"urls": { "type": "array", "items": { "type": "string" } },

"maxItems": { "type": "integer", "minimum": 1, "maximum": 1000 }

},

"required": ["urls"]

}

```

Ejecutas eso con `apify run` en local. Cuando funciona, haces `apify push` y el mismo código corre en un runtime serverless de Apify — escalando, con retries y con los resultados escritos en un dataset acoplado.

Ya no es un script. *Es una pieza componible en un sistema más grande.*

---

El Análisis (II): la Ola LLM le Dio la Vuelta a la Narrativa

Apify pasó de "raspamos webs" a "alimentamos modelos y agentes de IA". Ese giro no es cosmético. Es real, y cambia cómo deberías arquitecturar tus outputs.

Tres razones concretas:

1. Los sistemas RAG necesitan datos actuales que ningún periodo de entrenamiento de un modelo fundacional puede tener.

2. Los conjuntos de evaluación necesitan ground truth capturado hoy — no datos de hace seis meses.

3. Los frameworks de agentes permiten que un LLM invoque un scraper como tool a mitad de tarea.

La consecuencia práctica: en 2026, raspas para que un agente o un pipeline de datos consuma tu output. Eso significa JSON limpio y con esquema definido gana a HTML bonito, siempre.

Los tutoriales clásicos de scraping te enseñan a guardar el HTML crudo. El futuro es un Actor que devuelve schema-shaped JSON que un LLM puede parsear sin instrucciones adicionales.

---

El Framework de los 5 Movimientos del Actor

Vale, vamos a cortar el rollo teórico. Este es el Framework de los 5 Movimientos del Actor — el método único de operador que uso para cualquier recolector nuevo.

Paso 1: Forkea antes de escribir código

Busca en el Apify Store un Actor que se aproxime a tu objetivo. No reedites la rueda.

Los source code de los Actors del Store son open source. Clónalos en un proyecto local de Crawlee, inspecciona su `INPUT_SCHEMA` y entiende qué hacen antes de escribir una sola línea.

La ruta típica de 2026 es: reusar → forkear → customizar → desplegar. No empezar de cero.

Paso 2: Construye y estresa en local con Crawlee

Elige tu tipo de crawler deliberadamente:

• CheerioCrawler para páginas estáticas rápidas

• Playwright/PuppeteerCrawler solo donde el renderizado sea imprescindible

Activa siempre el session pool y configura la lógica de reintentos. Asume que el objetivo te va a bloquear. No lo asumas cuando ocurra.

Paso 3: Convierte el script en Actor

Envuélvelo en `Actor.main()`, declara el `INPUT_SCHEMA` (URLs, selectores, límites) y el output (dataset + key-value store). Prueba end-to-end con `apify run` en local.

Configura la compliance desde el día uno — respeta `robots.txt` y limita con `maxRequestsPerCrawl`:

```javascript

// Defiende tu reputación de IP desde la primera ejecución

const crawler = new CheerioCrawler({

maxRequestsPerCrawl: 500,

maxConcurrency: 5,

// Política cortés: no impactes al objetivo

});

```

Paso 4: Despliega y operacionaliza

`apify push` a la nube. Conecta el scheduling y monitoriza la tasa de requests bloqueados. Si ese número sube, quieres saberlo tú — antes de que lo note tu consumidor downstream.

Paso 5: Diseña para el pipeline de IA

Exponer el Actor terminado como API o tool invocable — mediante la API de Apify, una integración con LangChain o una definición de tool para un agente.

```javascript

// Un agente LLM llama a otro Actor como tool

// Esto convierte el scraping en una tool-call dentro del loop del agente

const resultado = await Actor.call('tu-usuario/raspador-ejemplo', {

urls: ['https://ejemplo.com/productos'],

maxItems: 20,

});

// resultado.dataset → JSON esquematizado, listo para el LLM

```

Trata el scraper como un microservicio de datos, no como un script de un solo uso. Esa es la mentalidad más a prueba de futuro que puedes adoptar.

---

Las Objeciones que te Estás Planteando Ahora

"¿Y por qué no ejecuto Scrapy en mi propio VPS?"

Para trabajos pequeños de un solo uso, self-hosting está genial. Dicho sin rodeos. Pero hay un impuesto operativo oculto: rotación de proxies, reputación de IP, backoff de reintentos, scheduling, durabilidad de almacenamiento y monitoring — todo se convierte en tu problema.

El cálculo cambia cuando necesitas recolección continua y resiliente. Ahí es donde un VPS barato te cuesta más en horas de operación de lo que ahorras en infraestructura.

"Si hay cientos de Actors listos en el Store, ¿para qué escribir código?"

Los Actors listos son un punto de partida, no una línea de meta. Los objetivos cambian su markup y su postura anti-bot en semanas. Necesitarás selectores custom, manejo de paginación, flujos de autenticación o reshaping de output.

El código open source es el producto real: forkéalo, adáptalo y solo paga por la operación.

"¿No es scraping una violación de términos de servicio o GDPR?"

Abordemos esto sin ambigüedad:

• `robots.txt` y Términos de Servicio no son lo mismo que la ley

• Los datos personales activan obligaciones de GDPR independientemente de la herramienta

• Apify incluye utilidades de cumplimiento con `robots.txt` y guías

Trata el scraping como una práctica de ingeniería defendible con guardarraíles. No como un hack de sombrero gris. Respeta `robots.txt`, limita tu tasa, no recolectes datos personales sin base legal — y estarás construyendo algo que sobrevive tanto a auditores como a GitHub Issues.

---

El Resumen que te Llevas

El scraping no es un problema de selectores CSS. Es un problema de orquestación anti-frágil.

Crawlee es el cerebro open source que gestiona sesiones, reintentos y detección de bloqueo. Apify es la capa de operación que ejecuta ese código como un Actor serverless — con scheduling, almacenamiento y escalado que nunca se ejecuta en tu portátil.

Los cinco movimientos: forkear el Store → estresar en local → envolver como Actor → desplegar con monitoring → exponerlo como data microservice para tu pipeline de IA.

La empresa que tiene scraping como operación, no como código, es la que gana cuando el objetivo cambia su markup a las 2 de la madrugada.

Construye el scraper que sobreviva a la ejecución 47. Porque esa ejecución va a llegar — la única pregunta es si tu pipeline la atraviesa en pie.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Crees que tu primer cliente fue tu validación. Que entregaste un trabajo brillante, que pagó a gusto, que te dijo "esto lo compraría cualquier empresa".

*Te has equivocado de diagnóstico.*

El 90% de las primeras productizaciones fracasan exactamente en ese punto. Y no por mala ejecución, ni por falta de calidad, ni por un producto feo.

Fracasan porque confundes una relación interpersonal con un segmento de mercado validado.

Tu primer cliente no compró tu producto. Compró tu capacidad de improvisar bajo ambigüedad. Compró que le cogieras el teléfono, que entendieras su contexto sin que te lo explicara del todo, que iteraras quince veces sobre un entregable mal definido.

*Ninguna de esas señales se transfiere a un desconocido.*

El error gemelo es definir el "producto" por los entregables que produjiste para un solo cliente. Empaquetas el informe. La plantilla. El dashboard. Y llamas a eso producto.

Es historia. No producto.

Llevo años enviando software en España. He visto docenas de agencias y freelancers morir en esta bifurcación. La señal no es que un cliente pagara una vez con entusiasmo. La señal es que varios desconocidos verbalicen el mismo dolor — sin tu ayuda y sin haberte visto nunca.

En este artículo te doy el checklist que separa el oro de la paja antes de que inviertas un solo día construyendo.

La Trampa del Sesgo de Supervivencia Inverso

Aquí está lo que nadie te dice cuando miras agencias que "productizaron tras su primer cliente".

Casi todas mintieron (o al menos, comprimieron la historia).

Cuando una agencia te enseña su servicio productizado en la web, suele haber tenido entre 5 y 10 clientes parecidos antes de empaquetar. Pero venden la narrativa como si el producto hubiera nacido del encargo número uno.

Ese es el sesgo de supervivencia inverso: solo ves a los que sobrevivieron al jinete del caballo blanco de un buen primer cliente. No ves a los cientos que empaquetaron el artefacto de un informe one-off y murieron en el intento porque ningún desconocido lo compró.

La cifra del 90% es un marco argumentativo, no un estudio externo. Pero el mecanismo es real y destruye más operaciones que cualquier error técnico.

Mecánica del fallo:

→ Un fundador entrega un proyecto bespoke excelente a un cliente.

→ El cliente, encantado, dice que "compraría esto como producto".

→ El fundador construye durante meses alrededor del entregable específico que produjo para ese cliente.

→ Saca el producto. Los desconocidos no lo compran.

→ El fundador concluye que "no tenía demanda". En realidad nunca la testeo.

El primer cliente no demuestra que haya demanda. Demuestra que tú sabes construir rapport y entregar bajo ambigüedad. Exactamente las dos competencias que menos se transfieren a extraños.

Un case study valida calidad de entrega y relación. No valida tamaño de mercado. Un segmento necesita repetibilidad y compradores que no te conocen. No anécdotas.

La Bifurcación Real: Datos Vivos vs. Informe Estático

Aquí está la decisión que separa al producto del servicio renombrado.

Todo proyecto que entregas produce uno de dos tipos de output:

❌ Informe estático — Un entregable one-off cuyo valor se deprecia a cero en el momento de la entrega. Una auditoría. Un informe de mercado. Un estudio de viabilidad. Un análisis de seguridad puntual. Se factura una vez, se entrega, se acabó. Si lo empaquetas, no has creado un producto: has creado un PDF con alcance. Eso es un servicio renombrado.

✅ Estado de datos vivos — Una necesidad que cambia por sí sola y exige actualización recurrente. El estado de cumplimiento normativo de una empresa. El inventario en tiempo real de un sector. El estado de las convocatorias de ayudas que afectan a un cliente. La operación de monitorización de algo que muta cada semana.

La distinción es brutal: el producto no es el entregable que produjiste. Es el umbral recurrente que dispara tu trabajo.

Pongo un ejemplo mío. Gestiono gestoriascercademi.com, un directorio de gestorías en España. Eso no nació de un informe estático para un cliente. Nació de un dato vivo: la geolocalización cambiante del tejido de asesorías y la demanda de búsqueda local que muta cada trimestre. El dato vivo justifica la actualización. La actualización justifica la recurrencia.

Un informe no. Un informe es una foto. Nadie paga una suscripción mensual por ver la misma foto.

Esto conecta directamente con el aprendizaje RaaS que ya documenté: el 90% de los nichos de suscripción mueren antes de lanzar porque el fundador elige datos que cambian demasiado despacio para justificar una suscripción mensual.

Si el dato del cliente cambia una vez al año, no hay razón para que nadie pague mensualmente. El nicho muere igual que muere el producto extraído del informe one-off. Misma raíz: falta de cadencia de cambio.

Diagnóstico obligatorio antes de construir nada:

→ ¿El valor que entregaste muere al entregarlo, o renace solo porque el mundo sigue girando?

→ ¿El estado del problema del cliente cambia sin que tú lo toques?

→ ¿Podrías escribir un cron job que detectara cuándo hay que regenerar ese valor?

Si respondes no a las tres, no tienes un producto. Tienes un servicio con buena presentación.

La Prueba de Recompra Sin Preguntar

El segundo error que mata la primera productización es testear la demanda preguntando.

"¿Comprarías esto otra vez, [nombre del cliente]?"

*Un "sí, me encantó" no es validación. Es cortesía post-entrega.*

La intención declarada post-entrega está contaminada por la relación. Ese cliente te debe favores, le caes bien, le resolviste un problema real. Por supuesto que dice que sí. Decir no sería un acto social desagradable.

El test real tiene dos capas:

Capa 1 — La necesidad viva existe sin ti. ¿El dato del cliente seguiría cambiando aunque desaparecieras? Si la respuesta es "no, el proyecto acabó y ya no hay nada que actualizar", no hay recurrencia. Da igual lo que diga el cliente.

Capa 2 — Desconocidos lo verbalizan solos. Encuentra al menos 3 desconocidos (no referidos por el cliente #1) que describan el mismo problema con sus propias palabras y el mismo umbral de dolor. Si nadie lo verbaliza sin que tú lo nombres primero, el segmento no existe.

Aquí la trampa es sutil: un primer cliente conseguido por recomendación cálida es una muestra contaminada. Su compra arrastra el capital social del referidor. No es una señal limpia de demanda; es una señal de que alguien influyente apostó por ti.

La señal limpia es la compra de un extraño que no te conoce, no ha visto tu trabajo y aun así paga por un output definido.

El Checklist de 5 Decisiones Antes de Construir Tu Producto

No hace falta esperar a tener 3 clientes parecidos para empezar. Tampoco hace falta rechazar al cliente #1. Lo que hay que hacer es tratarlo como fuente de datos y de relación, no como validación.

Corre este checklist antes de escribir una línea de código o diseñar una landing page. La validación y el arranque son actividades paralelas, no secuenciales.

Paso 1 — Diagnostica el Tipo de Necesidad

¿Datos vivos o informe estático? Si el entregable fue puntual, no es producto. Es historia. Si existe un estado de datos u operación que cambia y exige actualización, hay candidato a suscripción.

❌ "Mi primer cliente me pidió un estudio de mercado. Lo empaqueto como producto."

✅ "Mi primer cliente necesita saber cada mes qué ayudas públicas le afectan. El estado del mercado regulatorio cambia solo. Es dato vivo."

Paso 2 — Separa la Capa de Relación del Entregable

Haz dos listas:

→ Lo que el cliente #1 compró por confianza y rapport: iteraciones infinitas, ambigüedad, llamadas a cualquier hora, contexto que entendiste sin que te lo explicaran.

→ Lo que se puede estandarizar en un entregable definido que un desconocido aceptaría sin conocerte ni haberte visto jamás.

La primera lista es tu servicio consultivo. No muere: se vende por horas o por proyecto. La segunda lista es tu candidato a producto.

El error típico es empaquetar la primera lista y llamarla producto. Eso explica por qué tantos "productos" extraídos de un cliente son en realidad servicios renombrados con un PDF de alcance.

Paso 3 — Testea la Recompra Antes de Construir

No preguntes "¿te gustó?". Pregunta: "Si pudiera entregarte este resultado cada [mes/trimestre] sin que tengas que recordármelo, ¿lo contratarías — y a qué cadencia?"

Y aunque responda sí, no lo tomes como validación final. Un solo cliente feliz no es un mercado.

Un "sí, me encantó" no es validación. Es cortesía post-entrega.

Paso 4 — Encuentra 3 Desconocidos Que Verbalicen el Mismo Dolor

Sal a por compradores que no te conozcan. LinkedIn, comunidades sectoriales, búsqueda de problemas. La pregunta no es "¿te interesa mi solución?". La pregunta es "¿cuál es el mayor dolor que tienes con [el tema]?"

Si tres desconocidos describen el mismo problema con sus propias palabras y el mismo umbral de dolor — sin que tú introduzcas el concepto — hay segmento. Si nadie lo verbaliza solo, no existe.

Paso 5 — Define Precio y Alcance Alrededor del Resultado Recurrente

El precio se ancla al estado de los datos vivos, no a las horas empleadas ni al artefacto histórico que entregaste al cliente #1.

Tu producto cobra por mantener un problema del cliente en un estado controlado. No cobra por el informe que ya redactaste una vez.

La métrica de éxito no es "cuántos entregables produzco". Es "cuánto tiempo el problema del cliente permanece resuelto sin que yo intervenga — y qué pasa cuando deja de estarlo".

Ese segundo término es la oportunidad de recurrencia.

La Señal Que Buscas No Es un Cliente Feliz. Es un Extraño Que Paga.

Vuelvo al principio para rematar.

Un cliente feliz valida tu capacidad de construir relación y entregar bajo ambigüedad. Son competencias valiosas — se venden caras por proyecto. Pero no son un producto.

El producto nace cuando aíslas el dato vivo, lo separas del artefacto estático, y encuentras desconocidos que verbalizan el mismo dolor sin que se lo nombres.

El entregable del cliente #1 es historia. El umbral recurrente que activa tu servicio es el producto. La bifuración del dato vivo es el filtro que separa al operador que productiza del que renombra su servicio.

No hace falta esperar a tener tres clientes para empezar. Hace falta dejar de tratar al primero como validación y empezar a tratarlo como fuente de datos. Corre el checklist antes de construir. La validación y el arranque son actividades paralelas, no secuenciales.

El mercado no premia al que entrega bien un proyecto. Premia al que encuentra el dato que nunca deja de cambiar y construye alrededor de su ritmo.

Ahí está tu producto. Búscalo ahí, no en el informe que ya entregaste.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Crees que un nicho RaaS fracasa porque no tiene suficiente demanda. O porque el mercado está demasiado saturado.

*Te has equivocado de diagnóstico.*

El 90% de los nichos RaaS mueren antes de lanzar por una razón más simple y más estructural: el fundador eligió datos que cambian demasiado despacio para justificar que alguien te pague dos veces.

Lo he visto en los productos que he enviado desde España — conversoriaecnae.es, gestoriascercademi.com, Juridica Integral — y lo he visto en el análisis de nichos ajenos. El patrón se repite con precisión quirúrgica.

No es un problema de demanda. Es un problema de temporalidad.

El cliente racional no pagará una suscripción mensual por datos que solo cambian trimestralmente. Comprará una vez. Y en la segunda renovación te preguntará por qué no lo produce él mismo en casa.

Vamos a desmontar el mito y construir lo único que importa: el filtro que separa un nicho con suscripción viable de un informe de una sola venta.

---

El Espejismo de los Datos de Mercado

Empecemos por la trampa más seductora de todas: los datos de mercado.

El consejo convencional de selección de nicho dice que elijas donde la demanda sea más visible. Y no hay demanda más visible que los datos de mercado. Todo el mundo habla de la economía, de los tipos de interés, de la inflación de los precios.

*Pero el interés visible no es pago real.*

Todos tienen interés en la economía. Casi nadie tiene una partida presupuestaria recurrente dedicada a un feed económico genérico. El espejismo de los datos de mercado funciona así:

• La demanda "parece" alta porque todos hablan del tema.

• Los incumbentes y las fuentes gratuitas ya responden la pregunta.

• El cliente tiene alternativas en un feed RSS, en un informe trimestral gratuito, en un analista al que ya paga.

El resultado: un nicho que se siente vivo y que monetiza pésimamente.

El interés visible es la métrica equivocada. Lo que separa un nicho real de una charla de salón es una pregunta mucho más incómoda:

> ❌ "¿Le parece útil al cliente esta información?"

> ✅ "¿Qué está haciendo ESTE cliente HOY para resolver este problema?"

La disposición a pagar no se declara. Se demuestra con comportamiento existente.

---

Señal #1: Disposición a Pagar por Comportamiento, No por Interés

La primera de las tres señales que realmente importan es la disposición a pagar. Y el discriminador limpio es el comportamiento actual.

Un cliente que ya paga a un analista, una suscripción a una herramienta, o horas internas de un empleado para responder esta pregunta es un nicho real.

Un cliente que encontraría tus datos "útiles" es una conferencia, no un mercado.

El truco está en la evidencia concreta. Si tu cliente objetivo ya está gastando recursos en el problema, tienes presupuesto que desviar. Si no está gastando nada, estás pidiendo a alguien que cree un presupuesto nuevo — y esa es la venta más cara del mundo.

Esto explica por qué el nicho de datos de mercado se siente vivo pero monetiza mal: todo el mundo está interesado en la economía, casi nadie mantiene un gasto recurrente dedicado a un feed económico genérico.

La pregunta correcta no es "¿le interesa?" Es "¿en qué gasta hoy para responder esta pregunta?"

Busca uno de estos tres comportamientos:

• Paga una suscripción o herramienta que responde el problema de forma parcial.

• Paga horas a un analista o consultor que lo resuelve con fricción.

• Paga salario interno de un empleado junior que lo produce a mano cada semana.

Cualquiera de los tres significa que hay dinero circulando. El punto dos y el tres son especialmente interesantes — representan fricción que tu RaaS elimina.

---

Señal #2: La Cadencia de Cambio que Nadie Audita

La segunda señal es la que la mayoría de fundadores nunca inspecciona: ¿con qué frecuencia cambian los datos subyacentes?

Este es el motor oculto del churn. Y nadie lo audita antes de construir.

Piensa en la lógica del cliente. Si los datos cambian trimestralmente, su movimiento racional es comprar una vez y redecidir cada trimestre. ¿Por qué mantener una suscripción mensual para un informe que solo cambia cada tres meses?

Y aquí está el peligro real: en la segunda renovación, el cliente no solo redecidirá. Cuestionará si merece la pena producir los datos en casa.

Los datos con cadencia mensual o superior, o los datos dirigidos por eventos, fuerzan dependencia continua. Convierten el modelo de entrega en algo natural: no estás reportando, estás monitorizando.

La auditoría de cadencia

Antes de escribir una sola línea de código, haz esto:

Paso 1: Escribe el nicho candidato y su fuente de datos subyacente.

Paso 2: Define la cadencia natural de cambio: diaria, semanal, mensual, trimestral, dirigida por eventos.

Paso 3: Sé honesto. Si la respuesta es trimestral o más lenta, asume que estás construyendo un informe de una sola venta, no una suscripción — hasta que se demuestre lo contrario.

La regla es brutal pero simple: los datos que cambian despacio destruyen el modelo de suscripción por diseño.

Esto no significa un veto duro. Un nicho con datos trimestrales puede funcionar si el flujo de trabajo del cliente está construido alrededor de esa cadencia y la producción interna es costosa. Pero es la excepción, no la regla. Y el riesgo es estructural: en algún momento el cliente construirá la capacidad interna.

El bonus doble: datos frecuentes y desordenados

Aquí hay una capa que pocos analizan. Los datos que cambian a menudo pero en formas desordenadas y no estandarizadas son doblemente atractivos.

¿Por qué?

Porque la capacidad de reproducir de forma consistente un entregable — lo que he llamado en artículos anteriores el contrato de datos — es genuinamente difícil de copiar cuando la fuente de datos es caótica.

Los datos limpios que cambian a menudo pueden ser replicados por cualquiera con un cron job y un buen parser. Los datos desordenados que cambian a menudo requieren una arquitectura que tolere la suciedad, normalice los inputs y garantice consistencia. Eso es difícil. Y lo difícil es donde vive la ventaja competitiva real.

---

Señal #3: Limitadas Alternativas Competitivas — y las Dos Causas del "No Hay Competencia"

La tercera señal es la más malinterpretada del framework.

Ves un nicho donde no hay competencia y asumes luz verde. *Mal.*

La baja competencia tiene dos causas muy diferentes:

Causa A — Descuido: Los incumbentes ignoran el nicho porque les queda pequeño o porque está fuera de su foco. Aquí, luz verde: puedes ocupar la posición de especialista.

Causa B — Ausencia total de dinero: Nadie paga por ello porque no hay valor real. Aquí, luz roja: no hay competencia porque no hay mercado.

La prueba discriminadora es esta: ¿responde el incumbente a la pregunta adyacente bien y simplemente se salta esta? Si sí, es descuido — oportunidad. Si falla por completo, es ausencia de valor — trampa.

El mapa de sustitutos

Haz el mapa honesto de todas las alternativas que tiene el cliente hoy:

• Agregadores gratuitos que responden la pregunta con un feed RSS o un dashboard público.

• Vendors incumbentes que la resuelven como feature secundario de un producto mayor.

• La hoja de cálculo del cliente donde un junior la produce cada lunes con dolor.

El cliente ya resuelve el problema hoy. Tu preguntas es: ¿lo paga, lo sufre, y lo produce con fricción suficiente para que prefiera suscribirse a construirlo?

El nicho RaaS defendible no está donde no hay alternativa. Está donde la alternativa es tan dolorosa o costosa que el cliente prefiere pagar recurrencia a producirla él mismo.

---

El Filtro de las 3 Señales: La Intersección Que Buscas

Has visto las tres señales por separado. Ahora la jugada maestra: el nicho ganador existe solo en la intersección de las tres.

Propongo un framework que puedes ejecutar en un día — el Filtro de 3 Señales para Nichos RaaS.

Señal 1 — Disposición a pagar

Test de comportamiento existente. ¿El cliente gasta hoy dinero, herramientas o tiempo interno en este problema? Interesado no paga. Comportamiento actual paga.

Señal 2 — Frecuencia de cambio

Auditoría de cadencia. ¿Los datos cambian mensualmente o más a menudo? ¿Están dirigidos por eventos? ¿Y son lo bastante desordenados para que la producción consistente sea genuinamente difícil?

Señal 3 — Alternativas limitadas

Mapa de sustitutos. ¿Responde hoy alguien a esta pregunta? ¿La responde bien pero se salta tu nicho (descuido = oportunidad) o falla por completo (ausencia de valor = trampa)?

---

Cómo puntuar tu nicho hoy

Paso 1: Escribe tu nicho candidato en una hoja.

Paso 2: Audita la cadencia. Si es trimestral o más lenta, salvo excepciones demostrables, asume que no es una suscripción.

Paso 3: Busca evidencia de gasto existente. No intereses. Gasto. Un cliente que paga a un analista hoy es un mercado. Un cliente que encuentra tus datos útiles es una audiencia.

Paso 4: Mapea los sustitutos. Trata el "no hay competencia" como luz verde solo si el incumbente ignora el nicho por descuido, no porque no haya dinero.

Paso 5: Pregunta si el entregable soporta un contrato de datos. ¿Puedes definir un esquema estable y una salida de monitorización reproducible? Si los datos son demasiado inestables para contratar sobre ellos, lo que tienes es consultoría, no RaaS.

Solo el nicho que pasa las tres señales con luz verde merece tu arquitectura. El 90% de los nichos muere en la señal 2. Antes de escribir código, antes de onboarding un primer cliente — ejecuta el filtro.

---

Sobre la Cifra del 90% — Sé Honesto Contigo Mismo

Vale. Hablemos claro sobre la cifra.

El 90% es una estimación interna, un patrón observado a través de intentos de nicho RaaS que he analizado y construido. No hay un dataset auditado detrás. La fuente del mecanismo es el contenido original de este thread, no una estadística publicada.

*¿Y qué?

El valor intelectual no está en el número. Está en el mecanismo. Un 70%, un 80%, un 90% — cualquiera de esas cifras apunta a la misma conclusión: la mayoría de los nichos mueren por una decisión estructural evitable.

Podéis falsificar el filtro con vuestro propio nicho en un día. Poned el número por delante, sometedlo a prueba contra vuestras tres señales, y dejad que el resultado hable — no la cifra.

Esto es lo que separa un filtro de una opinión: los filtros se pueden falsificar.

---

El Patrón de Entrega Correcto Nace del Nicho Correcto

Un apunte final sobre el orden de las operaciones.

Los artículos anteriores de este thread establecieron dos verdades de arquitectura:

1. El producto de un RaaS no es el informe. Es la entrega fiable y habitual de monitorización.

2. La ventaja competitiva es la reproducibilidad y consistencia del entregable, resuelta con un contrato de datos.

La selección de nicho es el prequel de ambas. No puedes diseñar una arquitectura de entrega hasta que sabes si el nicho produce la frecuencia y la suciedad de datos que la justifican.

Los datos frecuentes y desordenados fuerzan la arquitectura de monitorización que ya describí. Los datos limpios y lentos no la justifican. El nicho que elijas determina qué arquitectura es viable.

No construyas la capa de entrega antes de auditar la cadencia. Es construir infraestructura para un problema que todavía no has confirmado que existe.

---

Resumen: Las Tres Señales y lo Que Viene Después

El 90% de los nichos RaaS mueren antes de existir — y el autopsy no dice falta de demanda.

Dice datos que cambian demasiado lento para que alguien te pague dos veces.

El nicho ganador es la intersección de tres señales:

1. Disposición a pagar demostrada por comportamiento actual, no por interés declarado.

2. Datos con cadencia mensual o superior, y lo bastante desordenados para que la producción consistente sea difícil de copiar.

3. Alternativas limitadas por descuido del incumbente, no por ausencia de valor.

Ejecuta el Filtro de las 3 Señales sobre tu nicho antes de invertir un solo euro en arquitectura o en onboarding de clientes.

El 90% de los nichos que auditas van a fallar el filtro. Y ese es el mejor resultado posible: fallar antes de construir es el único fallo que te ahorra dinero.

Los nichos RaaS que sobreviven no son los que tienen más demanda visible. Son los que alimentan una decisión recurrente con datos que nadie más puede entregar de forma fiable — y que el cliente ya paga por resolver hoy.

La próxima vez que te enamores de un nicho por su demanda visible, pregúntate una sola cosa:

*¿Qué está haciendo el cliente HOY para resolver esto, y cuánto le duele?*

Esa respuesta te dirá más que cualquier dashboard de keywords del mundo.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Porque empieza a escribir los tests. Los ejecuta. Lee el stack trace. Corrige su propio fallo. Y hace commit.

*Ese cambio en quién posee el loop vale más que cualquier upgrade de modelo. *

Durante años la industria asumió que el siguiente paso en IA para código era un autocompletado mejor o un chat inline en tu editor. El marco de Cursor y Copilot: el humano escribe, la IA sugiere.

El supuesto equivocado es que el modelo es el producto y la IDE es su casa.

Claude Code relocaliza la IA de "motor de sugerencias en el margen" a "trabajador autónomo que posee el loop completo desde una terminal". Y la consecuencia contraria es la que casi nadie ve:

*Lo que determina la calidad del output deja de ser la creatividad de tu prompt o el IQ del modelo. Se convierte en dos cosas: la higiene del contexto y el diseño de la gobernanza. *

Equipos que "solo apuntan al agente al repo" obtienen resultados mediocres y culpan al modelo. Equipos que tratan CLAUDE.md como una constitución y los tests como una red de seguridad obtienen un resultado distinto con el mismo modelo.

El cuello de botella se ha movido. Ya no está en el modelo. Está en el repositorio y en el proceso que lo rodea.

Por Qué la Terminal, y no la IDE, es Donde los Agentes Cobraron Vida

En una IDE, la IA es un motor de sugerencias. Propone un diff y espera a que un humano lo aplique.

No puede observar las consecuencias de sus propias acciones.

En una terminal, Claude Code puede editar un fichero, ejecutar tu suite de tests, leer el stack trace, volver a editar y re-ejecutar. Es un bucle de feedback cerrado donde el agente experimenta los resultados de lo que ha hecho.

Ese bucle de autocorrección es la diferencia arquitectónica entre un copiloto y un agente.

❌ Copiiloto: propone código → tú lo aplicas → tú ejecutas → tú corriges

✅ Agente: planifica → edita → ejecuta tests → lee el fallo → corrige → re-ejecuta → commitea

Es exactamente por eso que los vendors que corren a pegar "agéntico" al chat lateral de la IDE están peleando contra la forma equivocada. La fortaleza de la IDE — la proximidad a tu cursor — es precisamente lo que la mantiene como motor de sugerencias en lugar de agente.

La terminal no es un retroceso. Es el único lugar donde el loop cierra.

La Bestia del Loop Agéntico: Latencia y Tokens

Este diseño no es gratis. Un agente que de verdad posee el trabajo ejecuta decenas de llamadas de tool secuenciales por tarea: leer un fichero, editar este, ejecutar tests, leer el output, volver a editar...

Cada paso consume latencia y tokens.

Por eso Anthropic ha posicionado una clase de modelo más rápida y ligera como el caballo de batalla agéntico por defecto, reservando los modelos más grandes para planificación compleja y ediciones de alto riesgo.

*El throughput agéntico es un objetivo de optimización distinto a "mejor respuesta única". *

Si eliges el modelo solo por su mejor single shot, estás optimizando para el problema equivocado. Aquí el trabajo no es una respuesta. Son decenas de pasos secuenciales donde cada milisegundo y cada token cuentan.

El Contexto es el Nuevo Prompt Engineering — y CLAUDE.md es la Palanca

Llevamos años obsesionados con el system prompt. En los agentes, el texto de mayor palanca no es ese.

Es el fichero de memoria del repositorio, cargado en cada sesión.

Ejecutas `/init` en Claude Code y la herramienta escanea tu repo, analiza estructura y convenciones, y genera un CLAUDE.md base.

Ahí empieza el trabajo real. Porque el CLAUDE.md que genera la herramienta es un borrador. Tu trabajo es convertirlo en una constitución.

El Patrón de las Tres Categorías Críticas

Hay tres categorías de contenido en tu CLAUDE.md que determinan la calidad del agente más que cualquier otra cosa:

1. Comandos prohibidos: qué NO debe ejecutar jamás. Migraciones de base de datos destructivas, `git push --force`, `rm -rf` fuera de rutas de build.

2. Convenciones de estilo: cómo se escribe el código en *este* repo. No genérico. Específico. Naming, estructura de ficheros, manejo de errores.

3. Mapa de módulos: qué fichero pertenece a qué capa. Fronteras de responsabilidad. Qué tocar y qué no.

Un repo con arquitectura documentada con claridad, comandos prohibidos explícitos y convenciones impuestas produce resultados autónomos dramáticamente mejores.

Una sesión apuntada a un monorepo sin documentar se degrada a medida que el ruido llena la ventana de contexto.

Ahí es donde `/compact` (que resume la conversación para mantener el contexto dentro de los límites) y los subagentes existen para luchar contra esa degradación: podando y particionando contexto.

La Autonomía Convierte la Gobernanza en un Problema de Diseño, no de Confianza

El argumento estándar contra los agentes es simple: "no voy a dejar que una máquina ejecute comandos arbitrarios en mi repo. Una edición mala y lo corrompo."

Es la objeción más fuerte. Y merece una respuesta dedicada, con configuración real.

Claude Code gestiona la autonomía con capas: modos de permiso, hooks de ciclo de vida y checkpoints.

Los Tres Modos que Todo Equipo Debe Dominar

• `plan`: el agente propone cambios y espera tu aprobación antes de tocar un fichero.

• `default`: ejecuta comandos y ediciones tras pedirte confirmación en cada paso.

• `acceptEdits`: ediciones sin preguntar, pero aún controlado por los hooks.

Empezar en modo `plan` no es cobardía. Es la fase de aprendizaje donde calibras qué sabe hacer el agente antes de soltarle las riendas.

Los Hooks como Capa de Cumplimiento Normativo

La autonomía se vuelve segura cuando la política es código. Los hooks de ciclo de vida (`PreToolUse`, `PostToolUse`, `Notification`, `Stop`) se declaran en ficheros JSON de settings.

Este es el snippet que bloquea lo destructivo y te avisa cuando el agente se para:

```json

{

"hooks": {

"PreToolUse": [

{

"matcher": "Bash",

"hooks": [

{

"type": "command",

"command": "if echo \"$TOOL_INPUT\" | grep -qE 'rm -rf|git push --force|drop table'; then echo '{\"decision\":\"block\",\"reason\":\"Comando destructivo bloqueado por policy\"}'; exit 0; fi"

}

]

}

],

"Stop": [

{

"matcher": "",

"hooks": [

{

"type": "command",

"command": "curl -s -X POST https://tu-endpoint.webhook/agente-parado -d '{\"msg\":\"Claude Code ha terminado o fallado\"}'"

}

]

}

]

}

}

```

No le preguntas al agente "¿puedo confiar en ti?". Le defines qué le está permitido hacer y qué pasa cuando se para.

*Trata al agente como a un ingeniero nuevo con credenciales limitadas, no como a un oráculo omnisciente. *

Los equipos que triunfan con agentes tratan los hooks como una capa de cumplimiento. Bloquean comandos destructivos. Exigen aprobación antes de push. Notifican en Stop.

Esto reencuadra la crítica estándar — "la IA no es de fiar con mi código" — como un problema de ingeniería resoluble de scopes y políticas. No como un juicio moral sobre la IA.

Marco de Implementación: La Constitución del Repositorio

No es teoría. Es un orden de operaciones. Cinco pasos que convierten un agente desatado en un trabajador autónomo con guardarraíles.

Paso 1: Empieza Pequeño y Planifica Primero

Elige un repo pequeño y bien testeado para tus primeras sesiones. Lanza Claude Code en modo `plan` y deja que proponga cambios.

Revisa su plan antes de que toque un solo fichero.

Paso 2: Ejecuta `/init` y Cura el CLAUDE.md con Agresividad

El fichero generado es el esqueleto. Tu trabajo es codificar las tres categorías críticas: comandos prohibidos, convenciones y mapa de módulos.

Así se ve un fragmento bien curado:

```markdown

CLAUDE.md — Constitución del Repositorio

Reglas no negociables

• NO ejecutar migraciones DDL directamente en producción.

Usa siempre `prisma migrate deploy` via CI.

• NO usar `git push --force` en ramas compartidas.

• NO borrar ficheros fuera de `src/` sin aprobación humana.

Estilo

• TypeScript estricto. Sin `any` implícito.

• Funciones puras fuera de componentes. Hooks en `hooks/`.

• Errores se lanzan con causas nombradas, nunca genéricos.

Mapa de módulos

• `src/api/` → handlers de API. Sin lógica de negocio.

• `src/domain/` → reglas de negocio. Prohibido importar HTTP aquí.

• `src/repos/` → acceso a datos. Solo se habla con la base de datos.

```

Cada sesión carga este fichero. Cada promesa que le haces aquí es contexto durable que le ahorras al agente tener que adivinar.

Paso 3: Institucionaliza el Loop de TDD

Instruye al agente para que escriba primero un test que falle. Implemente hasta que la suite esté en verde. Y revises cada cambio con `git diff` antes de aceptarlo.

La suite de tests se convierte en tu red de seguridad para la autonomía. No el humano. El test.

Paso 4: Añade Política Encima de la Autonomía Antes de Escalar

Los hooks de `settings.json` que bloquean invocaciones de tools peligrosas y notifican en Stop. Capa de cumplimiento antes de soltar más autonomía.

Paso 5: Escala Solo Tras Probar la Confianza Local

Descompón el trabajo repetido en subagentes (ficheros Markdown bajo `.claude/agents/`) y comandos slash (`/changelog`, por ejemplo) bajo `.claude/commands/`. Las tools externas se conectan vía MCP servers.

Y cuando el agente demuestre fiabilidad local, gradúalo a ejecución headless (`.claude -p`), Agent SDK o GitHub Actions. Siempre con un gate de revisión humana obligatoria sobre el diff producido.

El Salto al Pipeline

El mismo loop que arregla un test local fallido puede programarse para hacer triage de pull requests o parchear issues automáticamente en cada push.

La consecuencia es un cambio de rol del ingeniero. Dedicas menos tiempo a escribir cada línea y más a definir política y revisar diffs producidos por el agente.

El gate de revisión se mueve más temprano. Y la suite de tests, no el humano, se convierte en la primera línea de defensa.

La Objeción del Repo Legacy

¿"Esto solo funciona en proyectos greenfield limpios; mi monorepo legacy es un caos y el agente se va a perder"?

Justo. Y parcialmente cierto.

Por eso el argumento honesto es el de la higiene del contexto: la curación de CLAUDE.md, `/compact`, los subagentes y la descomposición de tareas con scope limitado son precisamente las herramientas para codebases grandes y desordenados.

Hay que conceder la correlación entre calidad de documentación del repo, cobertura de tests y éxito agéntico. No sobrevender la herramienta.

Pero — y esto es clave — ese trabajo de documentación y tests es exactamente el que harías para que cualquier ingeniero nuevo fuera productivo. Un agente solo hace que ese coste tenga retorno más rápido.

La Verdad Incómoda

Claude Code no es un autocompletado mejorado con extra steps.

Un copiloto sugiere código mientras el humano posee la tarea. Claude Code posee la tarea de principio a fin desde la terminal, donde puede ejecutar comandos y observar resultados.

La diferencia de unidad de trabajo no es cosmética. Es arquitectónica.

Y la consecuencia es que el pato de los agentes no se decide por el hardware del modelo. Se decide por cuánta disciplina tienes en el repo: qué permites, qué documentas, qué bloqueas y qué testes.

El modelo ya no es el límite. Tu repositorio lo es.

Por eso el mismo agente que rinde mediocre en un monorepo sin documentar se convierte en un operario fiable en un repo con una constitución clara y una suite de tests que muerde.

Los que aprendan a tratar el CLAUDE.md como una constitución y los hooks como una capa de cumplimiento van a entregar software a una velocidad que los que pelean contra la forma de la herramienta no van a poder igualar.

*El próximo salto no va a venir de un modelo más listo. Va a venir de un repositorio mejor gobernado. *

Y la terminal pelada donde escribes `claude` y dejas de escribir — ese es el lugar donde se va a decidir todo.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Crees que el factor crítico de tu Research-as-a-Service es impresionar. Un dashboard brillante. Gráficos que se actualizan en vivo. Más fuentes de datos que tu competencia.

*Te has equivocado de diagnóstico.*

El producto que tu cliente compra no es el informe en pantalla. Es la certeza tranquila, llegando a tiempo, de que alguien sigue vigilando. Y esa certeza se entrega con push — no con un portal que el cliente deba recordar visitar.

Tu cliente casi nunca entrará en el portal. Si lo diseñas bien, eso no es un fallo. Es el objetivo.

El Error de Tratar tu Entrega Como un SaaS

Todo el pensamiento de producto mainstream optimiza para engagement. DAU. Time-on-page. Profundidad de sesión. Cuantas más visitas, mejor.

*Para un sistema de entrega, una visita es una señal de fallo.*

Significa que el cliente tuvo que gastar esfuerzo para obtener el valor que ya pagó. Significa que la monitorización no llegó sola. Significa que tu sistema le pidió trabajo.

La investigación no es un evento que se encarga. Es un hábito. Un sistema de entrega perpetua. Y el hábito se construye con repetición predecible, no con un portal brillante que nadie abre.

❌ Enfoque débil: Dashboard impresionante diseñado para que el cliente entre cada día. Métricas de engagement como KPI de éxito. Más features, más datos, más gráficos.

✅ Enfoque correcto: Portal de presencia cero. El cliente nunca necesita entrar. Las alertas, el timeline y los informes llegan solos. Una visita se investiga como una anomalía.

El valor que tu cliente renueva no lo demuestra el tráfico del portal. Lo demuestra la continuidad sentida de la monitorización.

Por Qué la Tranquilidad Supera a la Información

Un insight obliga al cliente a interpretarlo. Ese es trabajo cognitivo. Y el trabajo cognitivo es ansiedad.

La certeza viene pre-digerida. Elimina una preocupación de la carga mental del cliente.

Esto reencuadra cada decisión de entrega: el objetivo del informe, la alerta y el timeline no es ser brillante. Es estar presente y ser predecible.

Un informe mediocre que llega puntual cada martes entrega más valor percibido que un informe brillante que llega tarde o de forma esporádica.

Piénsalo: cuando el cliente abre su email y ve que la monitorización de esta semana ya está, una pequeña alarma mental se apaga. Todavía me están vigilando. Esa alarma que se apaga es el producto.

La información es la prueba del trabajo que gana la confianza. Pero la suscripción recurrente se compra por la fiabilidad.

El Contrato de Datos No es Burocracia. Es tu Foso.

Todo el mundo asume que la ventaja competitiva de un RaaS es el volumen de captura de datos. Más scraping. Más fuentes. Más cobertura.

*El foso no es eso. El foso es aburrido.*

La ventaja competitiva se define por lo reproducible y consistente que es el entregable — no por tener más datos que el vecino.

El problema de la consistencia se resuelve estructuralmente, con un contrato de datos y una arquitectura de tres capas. No añadiendo fuentes.

Sin un contrato definido por escrito, cada ciclo de entrega depende del humor de la persona que lo ejecuta, de la herramienta que esté de moda, de la fuente que decidió cambiar su formato.

Con un contrato, el entregable es auditable y predecible. El cliente puede planificar decisiones de negocio alrededor de un informe que siempre llega con la misma estructura. Esa predictibilidad convierte a un proveedor en infraestructura. Y la infraestructura justifica un contrato recurrente, no una compra puntual.

La arquitectura de tres capas existe precisamente para que esa consistencia sobreviva al caos de las fuentes de datos reales.

Tu Ventaja No es el Scraping. Es No Hacer Scraping de Más.

Veamos la arquitectura que lo sostiene. La pipeline se divide en tres capas con interfaces estables entre ellas:

Capa 1 — Captura: Recogida de datos cruda. Aquí es donde la gente se pierde añadiendo fuentes infinitas.

Capa 2 — Análisis: Procesamiento y transformación. Convierte datos en lo que el contrato exige.

Capa 3 — Entrega: Generación del entregable final. Informe, alerta, entrada de timeline.

El contrato es la interfaz. Las capas son la implementación.

Esto importa porque la consistencia del entregable debe sobrevivir al cambio de personal, al cambio de herramientas y al cambio de fuentes de datos.

Si el analista se va, la capa de análisis cambia. Pero si el contrato está bien definido, el entregable que recibe el cliente es indistinguible. Si una fuente de datos muere, la capa de captura se adapta. Pero el informe sigue llegando el martes con la misma estructura.

<img src="https://placehold.co/800x400" alt="Pipeline de tres capas con contrato de datos como interfaz" />

Eso es lo que convierte tu servicio en infraestructura. Y la infraestructura es lo que se renueva.

El Timeline Completa el Bucle del Hábito

La investigación deja de ser un evento que el cliente encarga y se convierte en un ritmo en el que puede confiar.

El timeline es la capa de cadencia: el mismo día, la misma estructura, cada ciclo.

El cliente abre su email un martes cualquiera y ve la entrada del timeline. Sin buscarla. Sin entrar en el portal. La monitorización es visible, continua y reduce la ansiedad sin exigir esfuerzo.

Esas entradas del timeline son la prueba tangible de que el trabajo sigue pasando. Son la evidencia que justifica la renovación. Un cliente que ve actividad cada ciclo no es un cliente que se pregunta qué está pagando.

La tranquilidad del cliente viene de poder predecir la monitorización, no de que le sorprendan con ella.

Presencia Cero No es Comunicación Cero

Aquí está la objeción más común: "Si el cliente nunca entra, ¿no parece que no estoy haciendo nada?"

Hay una distinción crítica entre presencia cero y comunicación cero.

La ausencia se refiere al esfuerzo del cliente. No a tu silencio como proveedor.

El sistema debe empujar regularmente y de forma visible. El timeline garantiza que el cliente vea actividad cada ciclo sin tener que buscarla. Las alertas llegan cuando cambia algo relevante. Los informes aparecen en su inbox con la cadencia pactada.

❌ Zero-communication: Construyes el portal, lo envías, y esperas a que el cliente entre. Si no entra, no ve nada. Y el mes que viene no renueva porque "no pasa nada".

✅ Zero-presence: El valor viaja en push. El timeline empuja entradas. Las alertas empujan notificaciones. Los informes empujan documentos. El portal existe como red de seguridad y registro de auditoría — no como destino.

El momento en que un cliente debe entrar al portal para obtener valor, tu sistema ya ha fallado.

La Regla del "No Construir" Como Estrategia de Entrega

Cada feature que añades al portal es coste de infraestructura recurrente. Y en un sistema de entrega, el scope es una responsabilidad.

Un sistema mínimo que hace una sola cosa — entregar monitorización predecible — supera a un portal rico en features que ocasionalmente se rompe o se desvía del contrato.

Pasa cada idea de feature propuesta por este filtro:

1. ¿Aumenta la sensación del cliente de ser monitorizado? O solo añade superficie, coste y modos de fallo.

2. ¿Reduce el esfuerzo del cliente? O solo existe para impresionar a otro proveedor de servicios.

3. ¿Está en el contrato? Si no está, no se construye.

La respuesta por defecto es no.

El Marco de los 5 Pasos para Diseñar tu Portal de Presencia Cero

Aquí tienes el orden exacto para implementarlo. Se llama el Modelo de Presencia Cero — una arquitectura de entrega donde el valor viaja en push y el portal es una red de seguridad, no un destino.

Paso 1 — Codifica el contrato de datos primero.

Escribe exactamente qué recibe el cliente cada ciclo: campos, formato, desencadenantes de cambio y cadencia. Cualquier desviación de ese contrato se trata como un incidente de producción.

El contrato existe antes que cualquier trabajo de UI. Sin él, todo lo demás es anécdota.

Paso 2 — Construye la pipeline de tres capas.

Captura → Análisis → Entrega. Interfaces estables entre capas. El contrato es la interfaz; las capas son la implementación.

Así la consistencia del entregable sobrevive al cambio de personal, herramientas y fuentes.

Paso 3 — Diseña el portal como presencia cero.

El canal de entrega por defecto es push: entradas de timeline, alertas y digest programados que llegan sin acción del cliente.

Define una visita como anomalía a investigar. No como un KPI a crecer.

Paso 4 — Instituye el timeline como ritual fijo.

El mismo día. La misma estructura. Cada ciclo.

La cadencia convierte la investigación de evento en hábito. Y el hábito es lo que el cliente renueva.

Paso 5 — Pasa cada feature por el filtro de "no construir".

¿Aumenta la sensación de ser monitorizado, o solo añade superficie y modos de fallo?

El tiempo es la única moneda irrecuperable. Cada feature que no construyes es tiempo que recuperas.

La Ventaja de la Quietud

En un mundo donde los proveedores presumen de dashboards y de volúmenes de datos, la jugada ganadora es la contraria.

Un sistema más pequeño. Más callado. Más fiable.

Que hace que el cliente se sienta vigilado, no impresionado.

La consistencia y la reproducibilidad superan al volumen de datos porque hacen que el entregable sea auditable y predecible. Y esa predictibilidad es lo que convierte a tu servicio en infraestructura — el único tipo de proveedor que justifica un contrato recurrente en vez de una compra puntual.

Tu producto no es el informe que aparece en pantalla. Es la alarma mental del cliente que se apaga cada martes cuando ve que la monitorización ya está hecha.

Diseña para esa alarma. Y acepta que el portal — si lo haces bien — quedará casi vacío.

Esa quietud es tu señal de que el sistema está funcionando. Un sistema de entrega que no exige visitas es el más cercano al verdadero productized services business model: uno donde el producto no es el contenido, sino la certeza de que nunca dejará de llegar.

---

Conclusiones clave:

→ El valor RaaS se entrega con push (timeline, alertas, digest), no con pull (un portal que el cliente debe recordar visitar).

→ Una visita al portal es una señal de fallo, no una métrica de éxito.

→ El contrato de datos es tu verdadero foso: hace el entregable auditable, predecible y renovable.

→ La pipeline de tres capas mantiene la consistencia cuando cambian personas, herramientas y fuentes.

→ El filtro de "no construir" es una estrategia de entrega, no solo de eficiencia.

El futuro no pertenece a quien construye el dashboard más impresionante. Pertenece a quien construye la certeza más silenciosa.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Crees que el problema de tu Research-as-a-Service es que no capturas suficientes datos. Que necesitas más scrapers, más fuentes, más volumen para que el servicio parezca serio.

*Te has equivocado de diagnóstico.*

Tu problema no es que te falten datos: es que tus clientes se dan de baja porque cada informe que reciben llega con una estructura distinta. Mientras el 80% de tu esfuerzo está en scrapear, la batalla que de verdad retiene clientes se libra en la capa de entrega — y la estás perdiendo.

El 80/20 está invertido. Y la mayoría de las agencias digitales que montan servicios de investigación nunca lo notan porque están demasiado ocupadas optimizando lo que pueden medir.

---

Por Qué Todos Creen Que el Problema es el Volumen de Datos

Hay una razón estructural por la que los equipos RaaS invierten el 80% de su esfuerzo en la capa de recolección: el scraping es medible. URLs visitadas, páginas descargadas, documentos procesados. Son métricas que puedes poner en un dashboard y mostrar a tu equipo.

La calidad de la entrega, en cambio, es subjetiva. Difícil de cuantificar. Requiere que alguien mire cada informe y juzgue si la estructura es coherente.

Esto es un clásico efecto Goodhart: los equipos optimizan lo que pueden medir, aunque sea lo que menos impacta en la retención. La recolección se ha commoditizado — Scrapy, Playwright, APIs públicas y LLMs para resumir hacen que traer datos sea barato y casi infinito — mientras que el churn se concentra en la última milla: estructura inconsistente, formato variable, citación descuidada, cadencia irregular.

❌ Lo que hace la mayoría: añade más fuentes al pipeline y mejora los scrapers

✅ Lo que retiene clientes: define un contrato de entrega, separa el pipeline en capas y automatiza el QA del entregable final

---

El 80/20 Invertido, en la Práctica

Piensa en tu propio pipeline. ¿Dónde se va el tiempo real de tu equipo?

• Collection: escribir y mantener scrapers, lidiar con cambios de HTML, rotar proxies

• Processing: normalizar datos, limpiar, verificar citas, estructurar hallazgos

• Delivery: dar formato final, revisar que todo cuadre, enviar al cliente

Si eres como el 80% de los operadores de RaaS, casi todo tu esfuerzo está en la primera capa. Y la primera capa es exactamente la que ya no produce diferenciación.

Aquí está la verdad incómoda: traer datos ya no es el trabajo caro. Es la normalización de estructura, la verificación de citas y el formateo lo que decide si tu cliente renueva. Los equipos que invierten en la última milla reducen retrabajo y aumentan retención sin añadir ni una sola fuente nueva a su pipeline.

Yo lo veo con mis propios productos. En conversoriaecnae.es o gestoriascercademi.com, el valor no está en cuántos registros capturo. Está en que cada entrega llega con la misma estructura, la misma cadencia y la misma fiabilidad — semana tras semana. Eso es lo que hace que un servicio de retención se sostenga.

---

El Content Lake Aplicado a Investigación

La solución estructural no es más scraping. Es una arquitectura de tres capas que separa la recolección del procesamiento y de la entrega, en lugar de un único monolito donde todo se mezcla.

Y hay una analogía perfecta que ya hemos cubierto en este hilo: Sanity.io no es un CMS. Es una base de datos de contenido (el content lake) con un editor open source encima. Los equipos fallan cuando buscan un dashboard en vez de escribir un esquema de contenido.

Traslada esa lección a tu RaaS y obtienes esto: en vez de producir un PDF por cliente, produces objetos de investigación estructurados — hallazgos, fuentes con URL y fecha de acceso, metadatos, nivel de confianza. Objetos que se pueden rebanar por cliente, actualizar incrementalmente y versionar.

El entregable final es una vista sobre los datos, no el almacenamiento. Quien entiende esto puede servir a diez clientes con la misma base de datos. Quien no, rehace cada informe desde cero.

Aquí está el contrato de datos que define cada entregable:

```json

{

"$schema": "https://example.com/contracts/research-deliverable/v1",

"type": "object",

"required": ["client_id", "topic", "generated_at", "findings"],

"properties": {

"client_id": { "type": "string", "pattern": "^cli_" },

"topic": { "type": "string" },

"generated_at": { "type": "string", "format": "date-time" },

"findings": {

"type": "array",

"minItems": 1,

"items": {

"type": "object",

"required": ["claim", "sources", "confidence"],

"properties": {

"claim": { "type": "string" },

"confidence": { "enum": ["high", "medium", "low"] },

"sources": {

"type": "array",

"minItems": 1,

"items": {

"type": "object",

"required": ["url", "accessed_at", "title"],

"properties": {

"url": { "type": "string", "format": "uri" },

"accessed_at": { "type": "string", "format": "date" },

"title": { "type": "string" }

}

}

}

}

}

}

}

}

```

Cada cliente es una vista sobre este mismo esquema. Cambias el `client_id`, el formato de salida, el template — y el contrato sigue siendo el mismo.

---

Tres Capas, No Un Monolito

Aquí está el fragmento clave del framework que te propongo. Se llama El Patrón del Contrato de Datos y tiene tres capas, cada una con su propio artefacto de entrada y salida:

Capa 1 — Collection (scrapea amplio y barato):

```python

scrape_wide.py — Capa 1: solo recolecta crudo, sin pulir

from scrapy import Spider

from datetime import datetime

class WideCollector(Spider):

name = "wide_collector"

Output: fichero crudo, sin normalizar

def parse(self, response):

yield {

"raw_html": response.text[:5000],

"url": response.url,

"crawled_at": datetime.utcnow().isoformat(),

SIN estructura de negocio. Eso es trabajo de la Capa 2.

}

```

Capa 2 — Processing (extracción y normalización con IA):

```python

normalize.py — Capa 2: objetos estructurados, listos para el contrato

from pydantic import BaseModel

class Finding(BaseModel):

claim: str

confidence: str # high | medium | low

sources: list[Source] # validados contra el contrato

def process(raw_records: list[dict]) -> list[Finding]:

LLM resume y estructura. La salida CUMPLE el contrato de datos.

return [llm_extract(record) for record in raw_records]

```

Capa 3 — Delivery (templates + QA + formato final):

```python

deliver.py — Capa 3: QA automático + formato por cliente

def validate_deliverable(payload: dict) -> bool:

errors = []

if "findings" not in payload or len(payload["findings"]) == 0:

errors.append("Sin hallazgos")

for f in payload["findings"]:

if not all(s["url"].startswith("http") for s in f["sources"]):

errors.append(f"Fuente inválida en: {f['claim'][:50]}")

if f["confidence"] not in {"high", "medium", "low"}:

errors.append(f"Confianza inválida: {f['confidence']}")

Un entregable que no pasa QA NUNCA llega al cliente

return len(errors) == 0, errors

```

Ninguna capa depende del formato de salida de otra. Puedes cambiar el scraper sin tocar el template. Puedes cambiar el template sin rehacer el pipeline de datos.

---

El Stretch Goal: Servir a Escala con una Base de Datos

Cuando separas las capas, algo mágico ocurre: puedes servir a más clientes sin más horas de trabajo.

Tu equipo ya no rehace el informe desde cero. Recompila datos, ejecuta la normalización, valida contra el contrato, y genera el formato del cliente. La IA puede recompilar, actualizar y re-formatear por cliente sin rehacer el trabajo.

Y aquí entra la lección bootstrapped que hemos cubierto antes en este hilo: no construyas una plataforma de entrega a medida "por si acaso". El tiempo es la única moneda irrecuperable, y la infraestructura especulativa se paga en velocidad presente. En un RaaS bootstrapped, esa velocidad es literalmente la capacidad de servir más clientes.

Usa herramientas existentes. Un content lake como Sanity, la API de Notion, o incluso un generador de documentación. El contrato de datos es tuyo; la infraestructura no tiene por qué serlo.

---

El Marco de 5 Pasos para Implementar el Patrón del Contrato de Datos

Paso 1 — Define primero el contrato de entrega. Un esquema único y versionado de cada entregable, ANTES de escribir un solo scraper. El cliente no compra datos: compra un formato, una estructura y una cadencia. Escribe el JSON Schema primero.

Paso 2 — Separa el pipeline en tres capas con SLAs propios. Collection scrapea amplio y barato. Processing normaliza con IA. Delivery aplica templates y QA. Que ninguna capa dependa del formato de salida de otra.

Paso 3 — Audita dónde se va tu esfuerzo real. Mide horas por capa durante un sprint. Si más del 80% está en Collection, rebalancea hacia Processing y Delivery. Ese es el 80/20 invertido que hay que corregir.

Paso 4 — Mide el churn por causa, no por volumen. Clasifica cada baja de cliente — estructura inconsistente vs. datos incompletos vs. precio. Deja que los datos de retención dirijan la hoja de ruta técnica, no las métricas de scraping.

Paso 5 — Trata cada entregable como dato estructurado, no como documento. Si el output vive en un content lake, puedes servir a diez clientes con la misma base.

---

Las Objeciones Que Vas a Querer Plantear (y Sus Respuestas)

"Los clientes se van porque la investigación está incompleta — necesito MÁS datos."

Ambos factores conviven, pero con pesos distintos. No lo asumas: haz entrevistas de churn y audita los entregables rechazados para clasificar el motivo real de cada baja antes de decidir dónde invertir. Verás que la estructura inconsistente duele más que el dato faltante.

"Estandarizar mata el valor a medida — el cliente paga por análisis personalizado."

El contrato aplica al contenedor — formato, estructura, citación, cadencia — no al contenido analítico. La personalización vive en la capa de contenido y la consistencia en la capa de formato. Son capas separadas. Exactamente el argumento de las tres capas.

"Esto suena a que nos convertimos en una empresa de software."

No. El content lake reutiliza herramientas existentes. Estás definiendo un contrato de datos, no construyendo una plataforma. El objetivo no es la tecnología: es la retención.

---

La Consistencia Es la Confianza

Durante años el marketing digital vendió el productoizado como un problema de adquisición. Consigue más clientes, haz más lead gen, escala el outreach. Pero la retención es el motor silencioso del productized services business model — y en un RaaS, la retención no se juega en las fuentes que scrapeas. Se juega en el formato que entregas.

La entrega de investigación es un problema de UX, no de ingeniería. La experiencia del cliente ES la estructura, el formato y la cadencia del entregable — no los datos que hay detrás. En un servicio donde el output es el producto, la consistencia es la confianza, y la confianza es la retención.

Deja de optimizar el scraping. Define el contrato, separa las capas y automatiza el QA del entregable. El 80% de tu esfuerzo está donde ya no importa.

Lo que viene después es un escenario incómodo para quienes siguen compitiendo por volumen: la ventaja ya no se construye con más datos, sino con la arquitectura que los convierte en confianza. La recolección se ha vuelto infinitamente barata. La consistencia, infinitamente valiosa.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

El flag que rompe el build

Activar `--turbopack` debería haber sido un cambio de una línea. Es lo que leía en la documentación de Next.js: el bundler nuevo, escrito en Rust, más rápido que webpack, empujado como su reemplazo natural. En mi cabeza la cuenta era sencilla. Pongo el flag, el build tarda menos, y me olvido. Lo puse. El build cayó.

No cayó una vez. Cayó cada vez, en el mismo punto, con el mismo error. Quitaba el flag y compilaba sin problemas. Lo volvía a poner y crasheaba otra vez, idéntico. Repetí el ciclo unas cuantas veces por pura incredulidad: el resultado no cambió en ninguna. Un fallo que se repite de forma determinista deja de ser un misterio: se convierte en un dato. Y el dato era incómodo: Sanity, el CMS con el que gestiono el contenido de Conversor, no soporta Turbopack.

Lo que estaba en juego no era un detalle cosmético. El build es lo que empaqueta el sitio que sirve los datos fiscales y la API. Un build roto significa una página caída y unos docs inaccesibles. Por eso me lo tomé como un problema de verdad y no como una curiosidad de bundler.

Lo que no pude arreglar

Aquí está la parte que más me costó aceptar. No es un bug que pueda arreglar desde mi código. Yo no escribo el plugin de Sanity; solo lo consumo. La incompatibilidad vive en una dependencia de terceros, y ahí no pinto nada. Tenía dos caminos. Perseguir el fallo durante días — probar versiones, abrir issues, leer código ajeno — o aceptar el dato y decidir.

Decidí lo corto. El build de producción usa siempre webpack: `npm run build`, sin flag. No es la opción más rápida, pero es la que no se rompe. Cuando despliegas cada semana, un build un poco más lento es un precio razonable por no levantarte con un deploy caído por culpa de una dependencia que no controlas.

Pero una decisión tomada una vez no basta, porque yo no soy el único que toca este repositorio.

La defensa en profundidad

Tengo un operador nocturno: un agente autónomo que corre tareas de mantenimiento mientras duermo. Ese agente podría reintroducir `--turbopack` de buena fe. Porque lo leyó en la documentación, porque es lo que se recomienda, porque en las instrucciones que le dejé nadie le contó lo del crash. No me fío de mi memoria para impedirlo, y no me fío de la suya.

Así que lo bloqueé de forma determinista, en dos capas.

La primera es `permissions.deny`, la lista de permisos que el agente no puede usar. Ahí, ese flag no existe: está denegado antes de que nada se ejecute. La segunda es `guard.mjs`, un hook que corre en cada paso y frena el flag antes de que llegue a tocar nada. Son dos mecanismos distintos, en dos puntos distintos del flujo: uno a nivel de permiso, otro a nivel de ejecución. Si una capa falla, queda la otra. Es defensa en profundidad, y el motivo es concreto: quiero que el flag no pueda volver a entrar por descuido, pase lo que pase. La redundancia no es paranoia; es lo que convierte un "no debería pasar" en un "no puede pasar".

Esto es la diferencia entre esperar que no ocurra y hacer que no pueda ocurrir. Yo ya no espero.

El build local no sirve como gate

La segunda lección tiró abajo un hábito que daba por bueno. Durante un tiempo verifiqué todo en mi máquina antes de subir nada: `npm run build` local, y si estaba en verde, adelante. El problema es que en Windows ese build local está roto para los códigos con asterisco. Los códigos IAE y CNAE con los que trabajo llevan `*`, y el build se atraganta con ellos en mi entorno. El resultado era un gate que me daba falsa seguridad o falsas alarmas, dependiendo del día, y que además no reflejaba lo que iba a pasar en producción.

Dejé de hacer gate en el build local. La corrección del build de producción se verifica solo en la preview de Vercel. Si la preview compila, el build está bien. Si no, no lo está. No hay grises. La preview pasó a ser la fuente de verdad, y el build local quedó como una comprobación temprana que no siempre está disponible y en la que ya no baso ninguna decisión.

tsc en verde no es next build en verde

La tercera lección es la que más me resistí a aceptar: un `tsc` en verde no prueba que un `next build` esté en verde. Son dos comprobaciones distintas, y yo las trataba como una sola.

El chequeo de tipos de TypeScript valida que los tipos cuadran: que una función devuelve lo que declara, que un objeto tiene los campos que debe. El build valida que el proyecto entero empaqueta: el bundler, los plugins, el CMS, todo junto y en orden. Puedo tener tipos perfectos y un build que crashea. Lo sé porque me pasó: `tsc` pasaba sin un solo error, y Sanity seguía cayendo con el flag. Eran dos preguntas distintas y yo solo miraba la primera creyendo que respondía por las dos.

Qué aprendí

Lo que me llevo es más simple de lo que parece. Cuando un fallo es determinista y no es mío, no lo persigo: lo bloqueo, y lo bloqueo dos veces. Y ya no me fío de una comprobación como prueba de otra. El chequeo de tipos responde a una pregunta, el build responde a otra, la preview responde a una tercera. Cada una necesita su verificación, y ninguna sustituye a las demás.

Lo demás — webpack en vez de Turbopack — es solo una línea en la configuración y dos capas de guardarraíl que me dejan dormir tranquilo.

Lo que publica ese build, si quieres verlo: https://www.conversoriaecnae.es/api/v1/docs

Los equipos que triunfan con Sanity son los que dejan de preguntar "¿qué pinta el dashboard?" y empiezan a preguntar "¿cuál es mi esquema de contenido?".

El resto fracasa. No por culpa de Sanity. Por culpa de su propio marco mental.

La sabiduría convencional dice: "un CMS es donde los editores escriben blogs, y eliges uno comparando dashboards, plugins y editores WYSIWYG". Eso es erróneo a tres niveles cuando hablamos de Sanity.

Primero: Sanity no tiene páginas. El contenido es JSON definido por esquema. Comparar dashboards es comparar la decoración cuando lo que eliges es la capa de datos.

Segundo: todo el mundo asume que headless = "sin edición visual". Falso. La colaboración en tiempo real y Visual Editing dan a los editores previews en vivo.

Tercero: la mayoría asume que las consultas necesitan GraphQL o REST. Sanity responde con GROQ, un lenguaje completo que supera a GraphQL típico para contenido relacional. Elegir Sanity significa comprometerte con un lenguaje que la mayoría de desarrolladores jamás ha oído nombrar.

*El take más contracorriente: la mayor debilidad de Sanity es también su mayor fortaleza. No hay producto hasta que escribes código.*

---

El Problema: Estás Comparando CMS Cuando Deberías Elegir una Capa de Datos

WordPress, Drupal, incluso Strapi: organizan el contenido alrededor de páginas o documentos con campos fijos.

Sanity lo organiza alrededor de un esquema que escribes en TypeScript. Arrays, objetos, referencias y bloques de portable text. La misma entidad puede renderizarse como página web, tarjeta móvil, layout de impresión o respuesta de API sin duplicación.

Pero eso significa que los stakeholders no técnicos necesitan que les expliques el esquema antes de siquiera ver un editor.

Ahí está el primer choque. Tu cliente quiere escribir un artículo. Tú le enseñas un fichero de TypeScript.

Y el segundo choque ocurre un mes después, cuando intentas la integración con herramientas esperando un endpoint REST y descubres GROQ.

❌ El enfoque equivocado: Buscas el mejor "CMS headless" comparando dashboards, WYSIWYG y plugins. Esperas un giro que te dé el panel bonito.

✅ El enfoque correcto: Asumes que estás eligiendo una capa de datos. El esquema es un contrato de programación, no una pantalla de ajustes. Y ese contrato vive en git.

El tercer choque es el más silencioso: la adquisición por parte de Contentful en 2025. Dos de los nombres más grandes del headless content se fusionaron por lógica de infraestructura y consolidación, no por listas de features.

Para ti, como desarrollador, es una señal clara: elige tu stack por modelado de datos y diseño de API, no por el roadmap del vendor actual. Porque el mapa de vendors se mueve debajo de tus pies.

---

La Evidencia: Lo que Sanity Realmente Despliega

Desmontemos la arquitectura. Sanity es, arquitectónicamente, una base de datos de contenido hospedada — el famoso content lake. El contenido se almacena como documentos JSON, no como páginas renderizadas. No existe una entidad "página" en el modelo de datos.

Esa pieza cambia todo.

El Studio es open source bajo licencia MIT, y es una aplicación React configurable. La interfaz de edición es código que tus equipos pueden extender o reemplazar. Se configura vía `sanity.config.ts`, no vía un panel de administración.

Y GROQ — Graph-Relational Object Queries — es el motor relacional. Proyecta, filtra, atraviesa arrays y desreferencia referencias con el operador `->`. Sin GraphQL. Sin fragamentos. Sin round-trips REST.

```typescript

// sanity.config.ts — el "dashboard" que eliges

import { defineConfig } from 'sanity'

import { structureTool } from 'sanity/structure'

import { schemaTypes } from './schema'

export default defineConfig({

name: 'default',

title: 'Mi Studio de Contenido',

projectId: 'abc123',

dataset: 'production',

plugins: [structureTool()],

schema: { types: schemaTypes },

})

```

Se acabó el comparar paneles. Esto es lo que eliges: una configuración de TypeScript que define cómo se modelo y edita tu contenido.

La evidencia está en el modelo de datos, no en el marketing.

---

El Análisis: Por Qué esto Importa Ahora, en 2026

La consolidación del mercado confirma el papel de Sanity. La adquisición por Contentful en 2025 reframe por completo la categoría. Dos gigantes del headless content se fusionaron y la lógica fue de infraestructura y consolidación: no listas de features.

Para ti, desarrollador, hay una lección práctica y urgente: tu contenido deja de ser documentos de un vendor y se convierte en datos versionados en git. El esquema vive en tu repositorio, se revisa en pull requests, se migra con commits, no con clics en un panel.

Eso es lo que ningún CMS administrado te ha podido dar jamás.

Y la edición visual disuelve la vieja línea entre headless y legacy. El Presentation tool y la colaboración en tiempo real dan a los editores previews en vivo sobre el frontend real. Lo que los críticos del headless siempre dijeron imposible — editar con contexto visual — es ahora el default.

El resultado práctico: "headless" ya no significa "a ciegas". El factor decisivo entre Sanity y un CMS legacy ya no es el preview. Es si quieres tu modelo de contenido versionado en git o atrapado en una base de datos opaca.

---

El Framework: El Patrón del Esquema Como Contrato

Paso 1: Scaffold y Acepta el Studio por Defecto

```bash

npm create sanity@latest

O, para un proyecto existente:

npm install sanity @sanity/client

```

Acepta el setup por defecto. Crearás una app Next.js o Remix con el Studio integrado. No te preocupes por personalizar aún. La personalización viene después, cuando el esquema esté estable.

Paso 2: Modela Contenido Como Código Primero

Resiste la tentación de empezar por la UI. Define cada tipo — post, autor, producto — como un objeto TypeScript con campos, validación y referencias.

```typescript

// schema/post.ts — el modelo de contenido ES TypeScript

import { defineField, defineType } from 'sanity'

export default defineType({

name: 'post',

title: 'Post',

type: 'document',

fields: [

defineField({ name: 'title', type: 'string', validation: r => r.required() }),

defineField({ name: 'slug', type: 'slug', options: { source: 'title' } }),

defineField({ name: 'author', type: 'reference', to: [{ type: 'author' }] }),

defineField({ name: 'body', type: 'blockContent' }),

defineField({ name: 'tags', type: 'array', of: [{ type: 'reference', to: [{ type: 'tag' }] }] }),

],

})

```

Este fichero es tu contrato. Vive en git. Se revisa en PR. Se versiona.

Paso 3: Consulta con GROQ a través de @sanity/client

Versiona tus queries en un único fichero. Usa el plugin Vision en Studio para iterar contra datos reales.

```javascript

// lib/queries.js — todas las queries versionadas en un sitio

export const postQuery = `*[_type == "post" && publishedAt <= now()]

| order(publishedAt desc) {

title,

slug,

"author": author->name,

"tags": tags[]->{label}

}`

```

*El operador `->` desreferencia referencias inline. Lo que en GraphQL serían múltiples fragments, en GROQ es una línea.*

Paso 4: Conecta a tu Frontend

```javascript

// app/page.js — fetch desde una app Next.js

import { client } from './lib/sanity'

import { postQuery } from './lib/queries'

export default async function HomePage() {

const posts = await client.fetch(postQuery, {}, { next: { revalidate: 60 } })

return <PostList posts={posts} />

}

```

Sanity sirve desde CDN por defecto. El caching es parte de la capa de datos, no un plugin.

Paso 5: Real-time en vez de Rebuilds Estáticos

Activa el draft mode o el preview. Usa `client.listen()` o el Presentation tool para actualizaciones de contenido instantáneas, en vez de rebuilds on-publish.

```javascript

// Escucha cambios en tiempo real — sin rebuild on publish

const subscription = client.listen(`*[_type == "post"]`)

subscription.subscribe(update => {

console.log('Contenido actualizado:', update.result)

// Invalidación selectiva de caché, no rebuild completo

})

```

Paso 6: Extiende el Studio para tus Workflows Reales

El editor es una app React que posees. Añade inputs custom, validación específica y plugins. Después itera sobre el esquema sabiendo que las migraciones son aditivas, no destructivas.

```tsx

// Custom input: valida slugs únicos vía API

import { useClient } from 'sanity'

import { StringInputProps } from 'sanity'

export function UniqueSlugInput(props: StringInputProps) {

const client = useClient({ apiVersion: '2026-01-01' })

// Verifica unicidad contra el content lake en tiempo real

return <input {...props} placeholder="Escribe un slug único..." />

}

```

El nombre de este patrón: El Patrón del Esquema Como Contrato. El esquema no es configuración. Es el contrato firmado entre editores, frontend y API. Todo lo demás — Studio, queries, previews — desciende de él.

---

Las Objeciones que Me Harías (y sus Respuestas)

"¿Por qué añadir GROQ al stack cuando ya conozco GraphQL? ¿No eleva la curva de aprendizaje y me encierra en Sanity?"

GROQ se aprende en una tarde. Viene con el client oficial. Y el contrato esquema-as-code reduce el riesgo de lock-in comparado con esquemas opacos de base de datos. La concesión honesta: el ecosistema de tooling es menor que el de GraphQL.

"El contenido JSON estructurado significa que no hay integridad relacional real — las referencias son strings que pueden quedar huérfanas."

El tipo `reference` de Sanity incluye reglas de validación. El trade-off: flexibilidad y evolución sin migraciones destructivas contra garantías de foreign keys estrictas. Si tu equipo necesita constraints ACID duros, reconsidera si un CMS es la herramienta correcta en absoluto.

"Es SaaS hospedado — ¿y si el servicio o el vendor fusionado cambia de rumbo tras la adquisición?"

El Studio es open source MIT. La API y la especificación GROQ son públicas. Puedes exportar y hacer backup del contenido vía la API. Mitigación real. Pero sé honesto: el content lake es un servicio administrado. Si necesitas self-hosting extremo, valora eso antes de comprometerte.

---

Resumen y Hacia Delante

El error colectivo es tratar Sanity como un WordPress sin interfaz. Lo que es: una base de datos de contenido donde el esquema es un contrato TypeScript versionado en git, consultada con GROQ, administrada por un editor React open source.

Los take-aways:

• El esquema es el producto. Todo lo demás desciende.

• GROQ reemplaza lo que a GraphQL le costaría fragments y round-trips.

• El editor es código que posees, no un dashboard alquilado.

• El contenido versionado en git es la razón real de elegir Sanity.

La frase que me repito cada vez que un cliente me enseña el "CMS": elige tu stack por el modelo de datos, no por la lista de features del vendor actual. El mapa de vendors se moverá. Tu esquema, versionado en git, permanece.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Crees que ser eficiente con el capital es gastar menos. Que la tanda de este mes, el plan de hosting más barato, el servidor compartido en vez del dedicado, te convierten en un fundador frugal.

*Te has equivocado de diagnóstico.*

El 89% de las startups bootstrapped construyen infraestructura que no necesitan — y la pagan en velocidad, la única moneda que no se puede recuperar. La eficiencia de capital no es cuánto gastas. Es qué decides no construir.

Este artículo no va de recortar presupuesto. Va de entender que tu función objetivo es distinta a la de una startup con financiación, y que cada decisión de arquitectura que tomas hoy se cobra en el único recurso que no vas a recuperar: tus horas de fundador. Vamos a desmontar la trampa, analizar el patrón por el que copiamos infraestructura ajena, y construir un framework de decisión que puedes aplicar esta misma semana.

---

---

El Problema: la Trampa de la Preparación

Mira tu arquitectura actual. ¿Cuánto de lo que montaste existe para servir a los usuarios que tienes hoy?

No. Lo montaste por si acaso.

Por si acaso llegan diez mil usuarios. Por si acaso el proveedor se cae. Por si acaso algún VC te pide escalabilidad en el due diligence. El mismo gesto que en una startup VC es racional — prepararse para escalar — es destructivo en una bootstrapped.

La razón es estructural. Una startup VC optimiza cuánto capital quema por unidad de crecimiento, porque su restricción es el capital disponible. Tú tienes capital acotado pero decides tu propia pista. Tu restricción real son las horas del fundador. Copiar patrones de infraestructura VC es copiar una solución diseñada para otra restricción: el mismo gesto es racional en un marco y suicida en el otro.

La asimetría que nadie nombra

Si tu startup nunca escala — el resultado más probable para la mayoría de bootstrapped — la infraestructura diferida nunca se paga. La construida "por si acaso" sí se pagó, en tiempo presente.

La deuda técnica de no prepararte solo se cobra si creces. La deuda de prepararte se cobra siempre, desde el día uno.

Aceptar esa asimetría es el primer paso. Es un trade entre rework hipotético y supervivencia real. Y la mayoría de bootstrapped nunca llega a la escala que preparan.

El coste oculto: el mantenimiento como impuesto perpetuo

Hay un matiz que rara vez se menciona cuando hablamos de infraestructura anticipada: construir no es el único coste. La infraestructura que montas por adelantado genera una deuda de mantenimiento perpetuo. Cada dependencia que añades, cada servicio que despliegas, cada abstracción que introduces, se convierte en algo que tienes que mantener, actualizar, depurar y documentar — no este trimestre, sino todos los trimestres mientras la startup exista.

Una cola de mensajes que configuraste "por si acaso el tráfico crece" no es un coste único. Es un sistema que se cae a las tres de la mañana, que necesita monitorización, que acumula deuda técnica cuando las librerías se actualizan, y que desvía tu atención de lo único que importa en una etapa temprana: encontrar producto-mercado-ajuste.

Es lo que algunos llaman el impuesto de la anticipación: pagas por adelantado, y luego pagas intereses todos los meses. El problema no es solo que la infraestructura anticipada cueste tiempo hoy; es que te lo sigue costando mañana, aunque nunca lleguen los usuarios que justificaban su existencia.

Cuando eres un equipo pequeño o un solo fundador, cada sistema adicional es un nodo de atención que compite con las tareas de distribución, onboarding y venta. Y en un equipo de una o dos personas, no hay nadie más que absorba ese coste.

---

---

La Evidencia: el Patrón Supabase y la Alineación del Mapa

Cuando digo que la infraestructura que crees propietaria en realidad ya existe, pongo un ejemplo concreto: Supabase.

Supabase no es un servicio de base de datos ni "Firebase con SQL". Es una capa de orquestación sobre PostgreSQL donde cada feature "mágica" es un primitivo de Postgres disfrazado de API. Tu REST API en Supabase es PostgREST — un primitivo existente. Tu auth es un wrapper sobre Postgres. Tu realtime es lógica de suscripción sobre los mismos mecanismos.

Nadie construyó eso desde cero. Lo empaquetaron.

La lección para el fundador bootstrapped es implacable: antes de escribir tu propio sistema de auth, tus colas, tu capa de API o tus cobros, busca el primitivo gestionado que ya lo resuelve. La mayoría de las features "mágicas" del SaaS son wrappers. Y adoptar el wrapper siempre es más eficiente que convertirte tú mismo en el wrapper.

El principio subyacente: la reutilización de primitivos

Vale la pena detenerse un momento en el mecanismo que hace que Supabase funcione, porque es el mismo mecanismo que debería gobernar todas tus decisiones de infraestructura.

PostgreSQL lleva más de treinta años en desarrollo. Tiene más de mil contribuidores. Ha sido probado en entornos de producción que gestionan petabytes de datos, en bancos, en aerolíneas, en sistemas de tráfico aéreo. Cuando decides que tu sistema de auth "propio" va a ser mejor o más apropiado que lo que Postgres ya ofrece, estás asumiendo que puedes replicar — en semanas de trabajo de un equipo pequeño — lo que una comunidad global ha tardado décadas en madurar.

Eso no es eficiencia. Es arrogancia disfrazada de control.

El patrón se repite en cada capa del stack. Las colas de mensajes llevan décadas resolviendo problemas de desacoplamiento. Los sistemas de pago como Stripe absorben la complejidad de compliance, fraude y conversión de divisas que jamás vas a replicar. Los servicios de auth gestionados manejan hashing, sesiones, OAuth, recovery de contraseñas y rate limiting — todos los casos borde que solo descubres cuando ya es tarde.

Cada vez que decides "construir lo nuestro", no estás ahorrando dinero. Estás aceptando una desventaja comparativa brutal frente a un equipo que dedica su existencia entera a ese problema concreto, y cuya solución puedes adoptar en una tarde de integración.

La micro-optimización no rescata un mapa desalineado

Segundo aprendizaje del patrón: las mejoras tácticas no producen eficiencia si el mapa estratégico está desalineado.

Puedes pulir tus tooltips, tus checklists de onboarding, tus email flows. Si tu modelo de crecimiento (PLG vs Sales-Led) y tu segmento de cliente no están alineados, ninguna mejora táctica reduce el resultado.

Es el mismo error de eficiencia a otro nivel. La micro-eficiencia táctica no rescata una asignación estratégica equivocada. La eficiencia empieza en el mapa, no en los tooltips. Ambos casos son gasto en actividad de bajo apalancamiento — y ambos comparten raíz: copiar el comportamiento del otro, en vez de alinear con tu restricción real.

Un ejemplo concreto en el contexto español: imagina una startup de gestorías que construye un sistema de onboarding impecable, con emails automáticos y checklists interactivos, pero que vende a clientes que deciden comprar por recomendación de su asesor fiscal, no por autoservicio. Todo ese esfuerzo de PLG optimizado está orientado a un modelo de crecimiento Sales-Led. Las gestorías compran cuando alguien les presenta una solución con confianza, no cuando rellenan un formulario. El resultado: horas y horas de micro-optimización que no mueven ni una décima la conversión.

La alineación entre tu modelo de crecimiento, tu segmento y tu producto es el mapa. Todo lo demás son detalles sobre un mapa equivocado.

---

---

Análisis: por Qué Copiar a los VC Es un Error de Marco, No de Ejecución

"Los VC también exigen eficiencia de capital — ¿qué tiene de distinto?"

Haz la pregunta correcta: eficiencia respecto a qué?

La eficiencia VC se mide como capital quemado por unidad de crecimiento, con capital abundante. La bootstrapped mide valor entregado por unidad de tiempo, con capital acotado. Misma palabra, funciones objetivo distintas.

Por eso copiar su infraestructura es un error de marco, no de ejecución. No estás ejecutando mal la misma función. Estás resolviendo un problema distinto.

El espejismo del falso empirismo

Pero hay una trampa adicional en este análisis, y conviene nombrarla con honestidad. Cuando observamos cómo operan una startup con financiación y otra bootstrapped, tendemos a pensar que ambas están jugando el mismo juego con recursos distintos. La realidad es más incómoda: están jugando juegos con reglas completamente diferentes.

Una startup VC tiene una ventaja que rara vez se menciona en los análisis de capital efficiency: su modelo de negocio no depende de la rentabilidad, sino de la valoración. La infraestructura escalable tiene un valor de señalización ante futuras rondas — demuestra que el equipo "piensa en grande". Aunque esa infraestructura nunca se use, está cumpliendo una función real: la de reducir el riesgo percibido por el inversor.

Tu caso es el opuesto. Tú no tienes a quién señalarle nada. Tu única señal de progreso es el producto funcionando y los usuarios pagando. La infraestructura anticipada no te compra nada en tu mercado; solo te cuesta tiempo que tu competidor — quizá con el mismo presupuesto — está usando para vender.

Cuando llamamos a esto un "error de marco", queremos decir exactamente eso: no te equivocaste en la ejecución de la infraestructura. Te equivocaste en el juego que estás jugando. Y el error más caro en cualquier negocio no es ejecutar mal una estrategia, sino ejecutar perfectamente la estrategia equivocada.

Los números correctos

Es momento de ser transparente sobre el titular de este artículo. El 89% es un encuadre provocador del análisis, no una estadística validada por un estudio externo. Trátalo como lo que es: un patrón que he visto repetirse cientos de veces en agencias y solos que envían software en España. Lo que importa no es el porcentaje exacto — es el mecanismo.

Pregúntate a tu alrededor. ¿Cuántos proyectos de España conoces con una cola de mensajes configurada para servir a menos de mil usuarios? ¿Cuántos sistemas de auth propios en productos que aún no han validado que alguien los quiere? ¿Cuántos clusters de Postgres con replicación en empresas que podrían pasar dos años sin llegar a los diez mil usuarios?

El porcentaje exacto da igual. La pregunta que de verdad importa es: ¿qué porcentaje de tu propia arquitectura actual existe para servir a los usuarios que tienes hoy? Si la respuesta te incomoda, sabes dónde está el problema.

---

---

El Triage de los Tres Pilares: el Framework de Decisión

Aquí está lo que puedes implementar hoy. Llamo a este filtro El Triage de los Tres Pilares — una regla de decisión, no un presupuesto. Todo gasto de tiempo debe justificarse contra el presente, no contra el futuro imaginado.

Paso 1: El test del usuario actual

Ante cualquier build — feature o infraestructura — exige que sirva a una necesidad demostrada por tus usuarios actuales.

No "el próximo segmento". No "cuando tengamos tracción". Los que están pagando hoy. Si no demuestran la necesidad, se difiere.

Esto suena más fácil de lo que es, porque el cerebro humano está diseñado para anticipar problemas antes de que ocurran. Cuando un usuario te dice "esto no me va bien", es natural pensar "y si crece, esto será peor". Pero la evidencia funciona al revés: la mayoría de las startups bootstrapped mueren por no tener suficientes usuarios, no por tener demasiados. El problema real nunca es la escala; es la distribución.

Un ejercicio concreto para este paso: escribe una lista de las cinco cosas que estás construyendo ahora mismo. Ahora tacha todas las que no puedas conectar directamente con una petición o dolor verbalizado y repetido por tus usuarios actuales. Si algo queda en la lista, justifícalo por escrito. Si no puedes, se difiere.

Paso 2: La auditoría de primitivos

Antes de escribir infraestructura propia, pregunta: ¿ya existe un primitivo gestionado que resuelve el 80%?

• ¿Auth? Supabase Auth, Clerk, Auth0.

• ¿Colas? Un cron job gestionado o una cola de un proveedor.

• ¿Capa de API? PostgREST, Directus, un ORM.

• ¿Cobros? Stripe, no tu sistema de billing.

Si existe, adopta el wrapper. No conviertas tu código en el wrapper.

Este paso tiene una regla de dedo: el 80% de las veces, el primitivo gestionado es suficiente. El 20% restante son casos donde tu necesidad real — no imaginada — excede lo que el primitivo ofrece. Solo entonces deberías considerar construir. Y aun así, con la disciplina de hacerlo en una capa fina por encima del primitivo, nunca reemplazándolo.

La clave está en el orden de evaluación. La pregunta no es "¿me conviene construir esto?" — esa pregunta mentalmente tiende a responder "sí" porque subestimamos sistemáticamente el coste de mantenimiento. La pregunta correcta es "¿existe una solución gestionada que resuelve el 80%?" — y solo cuando la respuesta es "no" pasamos al análisis de construcción.

Paso 3: El check de alineación

Toda optimización debe pasar por el mapa. Pregunta: ¿está alineada con mi modelo de crecimiento (PLG vs Sales-Led) y con mi segmento de cliente?

Sin alineación, las mejoras tácticas no reducen el resultado. La eficiencia empieza en el mapa.

Este es el paso que la mayoría de la gente salta, precisamente porque es el más incómodo. Comprobar la alineación significa admitir que quizá has estado optimizando en la dirección equivocada durante meses. Significa que puede que hayas construido un onboarding impecable para un producto que se vende por teléfono, o un sistema de trials generosos para un segmento que compra por urgencia, no por curiosidad.

El check de alineación no es un ejercicio de una tarde. Es una revisión trimestral en la que te preguntas: dado dónde estoy, dado mi producto y mi mercado, ¿cuál es la palanca correcta para crecer? ¿Adquisición? ¿Retención? ¿Expansión? Y cuando encuentras la respuesta, todos los gastos de tiempo — de infraestructura, de features, de marketing — deben filtrarse a través de esa palanca.

Paso 4: Time-boxea la preparación

Prepara solo hasta donde exige tu cuello de botella actual. Revisa trimestralmente.

No prepares para diez mil usuarios si tienes doscientos. El momento de pensar en escala es cuando el cuello de botella actual te lo pide — no antes.

Es tentador pensar en el cuello de botella como el momento en que "ya es tarde". En realidad, tiene una señal inequívoca: el día en que tus usuarios actuales empiezan a sufrir por un problema de rendimiento real, medido y no especulado. Cuando tu API responde en tres segundos y la gente se queja, es el momento de añadir un índice, una caché o un CDN. No antes.

Time-boxear la preparación tiene otra ventaja: te obliga a re-evaluar cada trimestre. La decisión que tomaste en enero — "no necesito escala" — puede revisarse en abril con datos nuevos. Tal vez el crecimiento fue real, tal vez el cuello de botella cambió, tal vez el mercado se movió. La revisión trimestral convierte la preparación en una decisión informada, no en un ejercicio de fe.

Paso 5: Mide velocidad, no escala

El precio de la infraestructura innecesaria se paga en velocidad de entrega de valor a los usuarios actuales.

Convierte la velocidad en tu métrica operativa de eficiencia. ¿Cuánto tarda entregar valor nuevo esta semana? Si la respuesta es "sigo manteniendo infraestructura", estás en la trampa.

La velocidad no es una métrica vaga. Es concreta: ¿cuántas features llegaron a producción este mes? ¿Cuántos bugs de los reportados se resolvieron esta semana? ¿Cuánto tiempo pasó entre que un usuario pidió algo y lo recibió? Todas esas son medidas de velocidad.

Cuando montas infraestructura anticipada, esa velocidad cae de forma invisible. No ves un descenso brusco — ves un goteo. Tres horas aquí, una tarde allá, un fin de semana resolviendo un problema de una cola que no necesitabas. Al final del trimestre, has entregado tres features en lugar de doce, y no puedes señalar un momento exacto en que perdiste las horas restantes.

Por eso la velocidad tiene que ser una métrica explícita, revisada en el mismo lugar que tu rentabilidad. El día que tu velocidad de entrega baja sin que la demanda de los usuarios lo justifique, tienes la respuesta: estás pagando el impuesto de la anticipación.

---

---

Implementación: Un Ejemplo Real

Imagina que estás lanzando un SaaS para gestorías en España. Tu stack podría ser:

• Frontend: Next.js con deploy en Vercel — Edge Functions gratuitas donde las necesites.

• Datos: Postgres gestionado. Nada de cluster propio ni replicación.

• Auth: primitivo gestionado. No escribas la tabla de sesiones.

• API: PostgREST o una capa fina sobre tu ORM. No construyas un framework propio.

• Cobros: Stripe Checkout. No tu sistema de billing.

❌ El enfoque equivocado: cluster de Postgres con réplicas para "preparar escala", sistema de auth propio, colas distribuidas, API construida desde cero, tres microservicios separados.

✅ El enfoque eficiente: un solo deploy, primitivos gestionados para todo lo que ya existe, y el tiempo ahorrado invertido en distribución, onboarding y venta.

El primer enfoque te lleva tres meses más lento. El segundo te coloca en el mercado esta semana.

Qué harías con las tres semanas que te sobran

Detente un momento y haz el cálculo. Con el enfoque eficiente, probablemente lanzas en dos o tres semanas. Con el enfoque equivocado, en tres o cuatro meses. Esa diferencia no es teórica: son cerca de doce semanas en las que no estás hablando con gestorías, no estás aprendiendo qué les duele de verdad, no estás iterando sobre feedback real.

¿Qué podrías hacer en doce semanas? Podrías hablar con cincuenta gestorías de tu mercado, identificar los tres dolores que se repiten, construir las features que los resuelven y validar que alguien paga por ellas. Eso es producto. Eso es negocio. Eso es lo que la infraestructura anticipada te roba.

Y hay un detalle que la mayoría de la gente pasa por alto: cuando por fin lanzas con el enfoque equivocado, tu arquitectura está diseñada para un tráfico que no tienes, pero no está diseñada para las cosas que sí has aprendido. Las gestorías te habrán pedido quince cosas que no anticipaste, y tu cluster de Postgres con réplicas no te habrá ayudado en ninguna. La flexibilidad que necesitas en etapa temprana no viene de la infraestructura; viene de la ausencia de infraestructura.

El timing de la migración

Una objeción legítima: "entiendo el argumento, pero ¿no es peor migrar después, cuando el tráfico conduce?"

La respuesta corta es: rara vez. Migrar a primitivos gestionados es, por definición, adoptar soluciones maduras que manejan la migración como un caso de uso estándar. La migración inversa — de soluciones gestionadas a infraestructura propia — es la que sí es costosa y peligrosa.

Recuerda la asimetría del principio: si nunca creces, la infraestructura diferida nunca se paga. Si creces, migrar de Postgres gestionado a un cluster propio es mover datos de un sistema maduro a otro sistema maduro — un trabajo de fin de semana con herramientas probadas. Lo que casi nunca ocurre es que necesites migrar en medio de un pico de tráfico sin margen de error. Cuando llega ese momento, si los primitivos gestionados se han quedado cortos, suelen ofrecer rutas de escalado vertical indoloras antes de que necesites pensar en la escala horizontal.

La migración futura es un problema blando. La velocidad presente es un problema duro. No intercambies el presente por un futuro hipotético.

---

---

Conclusión: Dejar de Construir Es la Estrategia

Esto no es frugalidad barata. Es capital efficiency con otra función objetivo: la infraestructura lean no es una restricción, es una ventaja competitiva que convierte tu recurso más escaso (tiempo) en velocidad de entrega.

Tres takeaways:

1. Tu restricción no es el dinero, es el tiempo. Diseña para él.

2. La "infraestructura propia" casi siempre es un primitivo disfrazado. Adopta el wrapper.

3. Sin alineación estratégica, ninguna micro-optimización te salva.

La trampa de la preparación se evita con una sola pregunta: ¿esto sirve a mis usuarios actuales, o a un futuro imaginado?

El bootstrap startup without funding — o con cualquier cantidad de funding — se construye con primitivos, velocidad y disciplina de no construir. Porque la decisión más eficiente que tomarás este trimestre no es qué montar. Es qué no montar.

Y esa decisión se toma hoy.

No esperes a que el próximo trimestre te traiga más datos. No esperes a que el tráfico crezca para justificar la auditoría. La auditoría se hace ahora, con lo que tienes, con los usuarios que tienes. Si algo de lo que estás manteniendo no sobrevive al test del usuario actual, al check de alineación o a la auditoría de primitivos, esa es tu oportunidad de recuperar horas.

La velocidad que recuperes esta semana — no la que recuperarás "cuando toque" — es la que decide si tu startup llega a ver el crecimiento que estás preparando. Porque la paradoja final es esta: toda la infraestructura que montas para el futuro imaginado la pagas precisamente con la velocidad que necesitas para llegar a ese futuro.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Cada "feature mágica" de Supabase es un primitivo de Postgres disfrazado de API.

Tu REST API tipo CRUD no es middleware personalizado — es PostgREST exponiendo tu esquema directamente. Tus usuarios autenticados viven en una tabla `auth.users` que puedes cruzar con JOIN contra tu negocio. Tu realtime se apoya en LISTEN/NOTIFY y replicación lógica. Tu modelo de autorización completo son políticas de Row Level Security evaluadas contra tu JWT.

Esto no es una paradoja curiosa ni un detalle de implementación para fanáticos de Postgres. Es la diferencia fundamental entre alquilar una plataforma y poseer un activo. Y una vez que lo ves, deja de ser posible volver a pensar en Supabase como "Firebase pero con SQL" sin sentir que estás haciendo trampa mental.

Eso significa que el miedo más grande que tiene la gente con Supabase — el lock-in — es exactamente lo que menos merece.

No estás encerrado en una plataforma propietaria. Estás pagando por una orquestación de componentes open-source pegados alrededor de un Postgres que puedes mover cuando quieras. La relación de dependencia no es con un vendor cerrado sino con un estándar de base de datos que lleva décadas establecido y que no depende de la salud financiera de ninguna startup de San Francisco.

---

El Reframing Que Cambia Cómo Arquitectas

Todo el mundo asume lo mismo: Supabase es "Firebase pero con SQL". Otro BaaS propietario al que te vas a quedar atado.

La realidad es la inversa. Con Firebase, tus datos viven detrás de una API propietaria y una migración significa reescribir queries. Cada llamada `firestore.collection('x').get()` es una invocación a un contrato que solo Google conoce y que Google puede cambiar cuando le plazca. Tu esquema no es tuyo: es una proyección de las reglas de Firestore. La migración no es un `pg_dump` sino una reescritura completa de la capa de datos de tu aplicación.

Con Supabase, el contrato entero es "es Postgres". El REST API se genera del esquema. La tabla de auth es SQL estándar. Un `pg_dump` se lleva todo contigo. Incluso las features que parecen más acopladas — el realtime, las políticas de seguridad — son extensiones de un motor de base de datos cuyo comportamiento está documentado en manuales que no dependen de un roadmap de startup.

El framework mental correcto: no estás comprando una base de datos. Estás comprando el ensamblaje — el pegamento entre Postgres, PostgREST, un servicio de auth en Go, un servidor de realtime en Elixir y storage compatible con S3.

Esos componentes existen todos por separado. Puedes montarlos tú mismo. Lo que Supabase vende es la integración: el DX, la cadencia de releases coordinada, el dashboard, las Edge Functions y el hecho de que todo funcione junta con un solo comando en local. Esa es la distinción importante — entre lo que es la plataforma y lo que hace la plataforma. Lo que hace es orquestar. Lo que es, sigue siendo Postgres.

Hay una analogía útil con el mercado de inteligencia artificial. Cuando un producto como Claude o GPT te da una API, estás comprando acceso a un modelo cuyo comportamiento solo puedes controlar mediante prompts y parámetros. Migrar entre proveedores significa reentrenar tus hábitos de prompting. Con Postgres, en cambio, el lenguaje de query no es una abstracción propietaria; es SQL, un estándar que precede a cualquier startup y que seguirá existiendo si Supabase desaparece mañana. La lección es la misma: cuando el contrato es un estándar abierto, la portabilidad es una propiedad del sistema, no una promesa del vendor.

---

Evidencia: Cada "Magia" es un Primitivo de Postgres

1. El REST API no existe — es tu esquema

Crea una tabla con su política de RLS y ya tienes un endpoint funcional sin escribir ni una línea de servidor:

```sql

-- Cero código de aplicación. Cero middleware.

create table posts (

id bigint generated always as identity primary key,

title text not null,

author_id uuid not null references auth.users(id)

);

alter table posts enable row level security;

create policy 'read all' on posts for select using (true);

create policy 'insert own' on posts for insert with check (auth.uid() = author_id);

```

Ahora `curl https://<tu-proyecto>.supabase.co/rest/v1/posts` con la cabecera de anon apikey devuelve datos. El endpoint no es una feature. Es tu tabla expuesta por PostgREST.

Detente un segundo aquí. Ese curl funciona porque PostgREST traduce cada petición HTTP a una query SQL sobre tu esquema. El filtro, la paginación, el select de columnas específicas: todo es SQL transpilado a HTTP. Si migras a un Postgres hosteado en cualquier otro sitio, puedes levantar PostgREST tú mismo en un contenedor y el mismo curl funciona con un cambio de URL. No hay código de aplicación que reescribir porque no había código de aplicación en primer lugar.

Este es el punto donde la gente suele hacer la pregunta obvia: "¿y si necesito lógica de negocio más compleja que un CRUD?" La respuesta es que PostgREST soporta funciones de Postgres expuestas como endpoints RPC, y para todo lo demás están las Edge Functions en Deno. Pero la arquitectura mental correcta es invertir el orden: empieza por el esquema y sube. No empieces por el servidor y bajes.

2. Realtime es un case study de reutilizar primitivos

`postgres_changes` usa replicación lógica — perfecto para eventos a nivel de fila que escalan. Presence y broadcast usan LISTEN/NOTIFY — ligero pero con límites de fan-out.

Saber cuál respalda tu canal te dice cuándo va a romperse. Presence de alta frecuencia entre miles de clientes no es lo que LISTEN/NOTIFY fue diseñado para soportar:

```js

const channel = supabase.channel('posts-live')

.on('postgres_changes', {

event: 'INSERT',

schema: 'public',

table: 'posts'

}, payload => console.log(payload.new))

.subscribe();

// El filtro se ejecuta en Postgres, no en el cliente

```

Lo que la mayoría de la gente no aprecia es la separación de responsabilidades que hay detrás. `postgres_changes` se implementa sobre el mecanismo de replicación lógica que Postgres usa desde hace años para replicación entre servidores. Cuando te suscribes con un filtro de schema/table/event, ese filtro se evalúa en el motor de Postgres, no en un hub central de mensajería. La consecuencia práctica: los payloads que llegan al cliente ya están filtrados, la autorización de RLS se aplica en la propia fila, y no hay una capa intermedia de eventos que duplique tus datos.

Esto importa porque el error clásico de las plataformas BaaS es tratar el realtime como una feature independiente de la base de datos. Aquí el realtime es un subproducto de la base de datos. Si entiendes que LISTEN/NOTIFY es broadcast puro sin garantías de orden ni persistencia, sabes que no debes construir un sistema de colas de mensajes sobre presence. Y si entiendes que la replicación lógica es el motor de `postgres_changes`, sabes que la fiabilidad del sistema depende de Postgres, no de un servicio de websockets propietario.

3. Tu auth es "solo una tabla" — y eso tiene las dos caras

```js

const { data } = await supabase.auth.signUp({ email, password });

// El usuario aterriza en auth.users. Una tabla normal.

// Queries posteriores viajan con el JWT:

const { data: posts } = await supabase.from('posts').select('*');

// RLS evalúa auth.uid() fila a fila. No hay middleware.

```

La cara buena: joins entre `auth.users` y tus tablas de negocio te dan analítica, paneles de admin y queries por usuario gratis. Cada tabla que quieras consultar con la identidad del usuario se cruza con una foreign key hacia `auth.users(id)` sin necesidad de sincronizar con un servicio de usuarios separado. No hay evento de usuario duplicado en un bucket de S3 ni una llamada a una API de gestión de identidades que no conoces.

La cara mala: los metadatos de usuario viven en la misma base que tus datos de producto. PII, retención y preguntas tipo GDPR se convierten en preguntas de base de datos, no de servicio aparte. Cuando borras usuarios de `auth.users`, tienes que pensar en cascada: ¿qué pasa con sus posts, sus comentarios, sus sesiones? ¿Anonimizas o borras en cascada con foreign keys? ¿Cómo manejas el derecho al olvido cuando tu esquema de negocio referencia a ese usuario? Estas preguntas no desaparecen con Firebase, pero con Supabase son preguntas de SQL que tú controlas, no campos de un formulario de consola de administración.

La decisión de diseño aquí es profunda: al mantener auth y negocio en la misma base, Supabase intercambia la separación de responsabilidades por la capacidad de hacer joins. Para la mayoría de los proyectos, ese intercambio vale la pena — es el mismo trade-off que hace cualquier base de datos relacional bien diseñada. Lo importante es que la decisión la tomas tú, con conocimiento, no una que el vendor tomó por ti.

4. Edge Functions y Storage siguen siendo pluggable

Las Edge Functions corren en Deno y Storage es compatible con S3. Nada propietario:

```js

// Deno.serve: la lógica de negocio corre fuera del app server

Deno.serve(async (req) => {

const { data } = await supabase.from('posts').select('*');

return new Response(JSON.stringify(data), {

headers: { 'Content-Type': 'application/json' }

});

});

```

Storage es un caso particularmente revelador. El API de storage de Supabase es un prefijo de S3: objetos, buckets, URLs firmadas para uploads y downloads, políticas de acceso por bucket. Si mañana decidieras mover tus archivos a cualquier proveedor S3 — AWS, la nube de tu empresa, MinIO en tu servidor — el único coste es cambiar el endpoint y reconfigurar los buckets. Los archivos son tuyos, el API es estándar.

Y para las Edge Functions, Deno es un runtime de JavaScript/TypeScript open-source que puedes ejecutar en cualquier sitio. La contribución de Supabase aquí es el gestionado: el deploy con un solo comando, el autoscaling, la integración con la base de datos. Pero el código que escribes no depende de ningún SDK propietario. Es el mismo patrón que en el resto de la plataforma: el ensamblaje es de Supabase, el material es estándar.

5. Todo es self-hostable

Un Docker Compose levanta Postgres más la API, auth, realtime, storage y studio localmente. `docker compose up` en supabase/docker arranca el stack entero.

Esto no es un truco de marketing. Significa que puedes hacer tu desarrollo local completo sin tocar la nube, con tus migraciones, tus policies y tus tests. Y significa — esto es lo importante— que el stack completo es reproducible fuera de la plataforma hosted. Vale la pena enfatizar el contraste con el resto del mercado BaaS, donde el "entorno local" suele ser un emulador con un subconjunto de features. Aquí no hay emulador: es el mismo código, el mismo Postgres, los mismos binarios.

---

El Impuesto Oculto Real: tus Hábitos, No el Vendor

Aquí está la paradoja del lock-in.

Con Firebase o Firestore, el impuesto es estructural: tus datos viven detrás de una API propietaria y la migración significa reescribir queries. Ese es el motor de negocio. El vendor gana cuando te quedas. El ecosistema completo — las reglas de seguridad de Firestore, el SDK, el modelo de documentos — se diseña para que la fricción de salir sea máxima.

Con Supabase, el "impuesto" solo existe si tú lo creas:

❌ Si construyes tablas clickeando en el dashboard y escribes lógica de autorización en el cliente, te has encerrado tú mismo. Da igual que el Postgres subyacente sea portable. Lo que se ha vuelto inportable es tu proceso: tu esquema no está versionado, tu seguridad no está en la base de datos, y el conocimiento que has acumulado sobre tu propio sistema vive en clicks de interfaz que no puedes reproducir en otro Postgres.

✅ Si versionas tu esquema como migraciones SQL y pones tu seguridad en RLS, tu contrato con Supabase es trivial de romper. El `pg_dump` se lleva los datos, las migraciones se llevan el esquema, las policies se llevan la seguridad, y un PostgREST levantado localmente replica el API.

El riesgo de lock-in no es el vendor. Son tus hábitos de equipo.

Si dependes de clicks en el dashboard y lógica client-side, te has encerrado independientemente de lo portable que sea el Postgres debajo. El Postgres no te va a salvar de un proceso que no versiona el esquema.

Esto conecta con una verdad más general del software: la fricción de migrar no la crea la tecnología, la crea el conocimiento tácito acumulado sobre la tecnología. Si ese conocimiento está en SQL versionado y policies documentadas, es transferible. Si está en la cabeza de la persona que clickeaba el dashboard, no se va a transferir nunca.

---

RLS Como Modelo de Seguridad: el Cambio Mental

Aquí va el cambio de chip que poca gente explica bien.

El frontend habla con la base de datos directamente. Eso significa que la autorización tiene que vivir en la base de datos o no existe. Esto invierte la asunción clásica de "confía en el app server".

En una arquitectura tradicional, el servidor filtra: el cliente pide, el servidor decide. Con Supabase, el cliente puede ejecutar queries directamente contra el REST API. Si la política de RLS no está en la tabla, la fila es visible y editable para cualquiera con una API key de anon. Nada te protege. La seguridad deja de ser un middleware y se convierte en una propiedad del esquema.

Esto tiene implicaciones de diseño que van más allá de "escribe un `create policy`". Por ejemplo:

• Cada política debe evaluar el JWT con `auth.uid()` o `auth.jwt()`. No puedes confiar en un campo booleano guardado en el cliente.

• Las políticas se evalúan por fila. Una query con un JOIN que cruza tablas con políticas distintas aplica cada política en su tabla. Entender cómo se componen las políticas entre joins es fundamental para no filtrar datos por accidente.

• Las funciones de Postgres que usan `security definer` se saltan las políticas de RLS. Son una herramienta potente — para servicio a servicio o para lógica que necesita traspasar la seguridad por fila — pero también un riesgo si no se controlan.

El coste de depuración es real: una policy demasiado permisiva es silenciosa. Y una query que devuelve vacío cuando esperabas datos puede dejarte horas mirando un SELECT que debería funcionar.

Por eso el desarrollo local con `supabase start` y testear policies en SQL no es negociable. Y por eso el modelo documentado de Supabase es "RLS en cada tabla con checks de `auth.uid()`", no guardias en el app layer.

El impuesto de depuración se aprende. Y se paga solo en seguridad.

---

El Protocolo de Salida Ensayada

Este es el framework que te permite soltar Supabase cuando quieras — y el que convierte la portabilidad en una feature, no en esperanza.

Paso 1: Versiona tu esquema como migraciones desde el día uno

Nada de clickear tablas en el dashboard. Usa `supabase db push` o una carpeta de migraciones versionada. Esto es lo que hace real la afirmación de portabilidad. Cada cambio de esquema, cada policy, cada función de Postgres es un archivo `.sql` que tu equipo revisa en un pull request igual que revisa el código de la aplicación. Si mañana cambias de plataforma, el esquema no vive en Supabase: vive en tu repositorio.

Paso 2: RLS en cada tabla antes de escribir lógica de autorización

Pon tus policies (con `auth.uid()` y `auth.jwt()`) antes de escribir cualquier guardia en el app. RLS es la única fuente de verdad para el control de acceso. La regla es simple: si una tabla no tiene RLS habilitada con al menos una policy, es una tabla pública o una tabla rota. No deberían existir tablas en esa zona gris.

Paso 3: Diseña tu esquema de auth intencionalmente

Referencia `auth.users(id)` con foreign keys. Trata la tabla de usuarios como parte de tu modelo de datos. Auth y negocio conviven en una sola base consultable. Preguntas como "¿qué usuarios han escrito más posts este mes?" son un JOIN, no una integración con un servicio externo.

Paso 4: Usa Realtime con filtros en servidor

Suscríbete con `postgres_changes` y filtra por schema/table/event. Nada de suscribirte a tablas enteras y filtrar en el cliente. Payloads pequeños y autorización dentro de Postgres. El filtro en el cliente es una invitación a enviar datos que el cliente no debería recibir y a escalar un fan-out que no necesitas.

Paso 5: Ensaya el drill de salida antes de necesitarlo

Periódicamente, prueba un restore de `pg_dump` en una instancia de Postgres puro:

```bash

supabase start # Postgres local + todos los servicios

supabase db push # migraciones versionadas

pg_dump -Fc ... # tu base entera se va contigo

```

"soltar Supabase en cualquier momento" es una operación ensayada, no una esperanza. Igual que se ensayan los disaster recovery plans en producción, ensayar la migración fuera de la plataforma te da dos cosas: la confianza de que puedes hacerlo, y el diagnóstico temprano de cualquier cosa que se haya acoplado accidentalmente a la plataforma.

---

La Pregunta "¿Por Qué No Montarlo Yo Mismo?"

Todos los componentes existen por separado. Postgres + PostgREST + un servicio de auth en Go + un servidor de realtime en Elixir + S3.

¿Por qué no saltarte Supabase y montarlos tú?

Por la misma razón por la que nadie monta su propio corredor de mensajes antes de lanzar un MVP: el valor no está en las piezas, está en el ensamblaje. El DX local, el dashboard, el workflow de migraciones, las Edge Functions en Deno y la cadencia de release coordinada entre componentes.

Puedes reconstruir el ensamblaje si tienes el apetito de operaciones. No quieres tenerlo.

Piénsalo en términos de coste de oportunidad. Cada hora que dedicas a parchear el realtime de Elixir o a mantener actualizado tu auth server en Go es una hora que no dedicas a tu producto. El ensamblaje de Supabase ya está resuelto, testado y versionado. Lo que te queda a ti es lo único que de verdad importa: el esquema, las policies y la lógica de negocio. La diferencia entre comprar el ensamblaje y construirlo no es el dinero — es la atención.

Existe, eso sí, un escenario legítimo para montarlo tú mismo: si tu equipo tiene una necesidad operativa que el ensamblaje hosted no cubre — una red privada estricta, compliance de datos que prohíbe proveedores externos, o un volumen de throughput que no justifica el coste del hosted. En esos casos, el hecho de que todo sea open-source y self-hostable es exactamente la salida que necesitas. Ni siquiera en ese escenario te quedas atrapado: puedes empezar hosted y migrar a self-hosted cuando la escala lo justifique, con la certeza de que los componentes son los mismos.

---

Conclusión

Supabase no es un servicio de base de datos. Es un Postgres con una capa fina de orquestación encima — y cada "feature mágica" es un primitivo de Postgres disfrazado de API.

Eso invierte la conversación sobre lock-in. Con Firestore, tu impuesto es estructural. Con Supabase, el único impuesto que pagas es el que te impones con clicks en el dashboard y lógica client-side.

La lección real del debate supabase vs firebase 2026: no estáis eligiendo entre dos BaaS. Estáis eligiendo entre una API propietaria que os cobra por quedarse y un Postgres portable que se va con vosotros en un `pg_dump`.

El ensamblaje lo alquila. La base de datos es vuestra.

Y eso, a la larga, es la diferencia que importa. Porque el software que sobrevive a sus vendors no es el que tiene el mejor DX ni el ecosistema más brillante — es el que se construye sobre estándares que cualquiera puede ejecutar. Postgres lleva décadas demostrando esa longevidad. Supabase, al elegir envolverlo en lugar de reinventarlo, ha hecho algo más inteligente de lo que parece a primera vista: ha convertido la base de datos más fiable de la industria en un servicio moderno sin renunciar a lo que la hace fiable. Ese es el trade-off que merece la pena hacer.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Crees que tu churn es un problema de producto. Que si la feature es mejor, el diseño más claro, o el precio más justo, la retención subirá.

*Te has equivocado de diagnóstico.*

La cifra citada en la industria —73% de los SaaS que fracasan— no apunta al código. Apunta al día 1: el onboarding entrega el mapa equivocado desde el primer login.

El onboarding no es UX. No es un checklist bonito ni un tour de producto pulido. Es un mapa estratégico que guía al usuario hacia el valor. Y si el mapa es el equivocado, una ejecución perfecta lleva al usuario al destino equivocado. O lo deja perdido a mitad de camino.

El 73% de los SaaS no fracasa por tener churn alto: fracasa porque el churn es solo el síntoma tardío de un desajuste que empezó el día 1.

Piensa en términos de navegación real: si un GPS está mal configurado, por muy bonita que sea la interfaz, por muy fluidas que sean las instrucciones paso a paso, te llevará a una rotonda equivocada o a un callejón sin salida. El diseño del GPS no es el problema. El destino lo es. En SaaS ocurre exactamente igual: puedes tener el mejor tooltip del mercado, el wizard más elegante y el checklist más gamificado, pero si el destino al que conducen no coincide con el valor real que tu producto puede entregar al segmento que lo usa, todo ese esfuerzo táctico se pierde.

Este artículo va a desmontar el ciclo completo: por qué el churn miente, cómo leer la señal real en los primeros 7 días, por qué el mapa correcto depende de tu modelo de crecimiento y de tu segmento, y qué pasos concretos puedes dar esta semana para diagnosticar (y corregir) el mapa antes de que sea tarde.

---

El Churn Miente. El Comportamiento de los Primeros 7 Días Dice la Verdad.

Aquí está el problema de fondo: el churn es una métrica agregada y rezagada. Es un indicador que llega meses tarde y culpa al producto cuando el verdadero culpable es el desajuste entre modelo de crecimiento y segmento de cliente.

Cuando el churn aparece en tu dashboard, el fracaso del onboarding ya ocurrió hace semanas. Los usuarios ya se fueron. Los datos ya son historia.

Las señales reales viven en los primeros días:

→ Tasa de activación por segmento

→ Tiempo hasta el primer valor

→ Abandono de la acción core

→ Features que se ignoran sistemáticamente

Estas son métricas líderes. Te dicen en días lo que el churn te contará en meses. Y te dicen *dónde está el desajuste, no solo que* existe.

Imagina que pilotas un avión y tu único instrumento es el altímetro que marca la altitud del aeropuerto de destino. Si vas rumbo a otra ciudad, solo te enterarás cuando ya sea demasiado tarde para corregir. Las métricas líderes del onboarding son tu giroscopio y tu brújula: te dicen si estás en el rumbo correcto mientras aún tienes tiempo de corregir. El churn es el altímetro: útil para confirmar que aterrizaste donde no debías, inútil para evitar el error de rumbo.

Concretamente, hay una diferencia operativa importante entre ambas familias de métricas. El churn mensual (MRR churn o logotipo) se calcula sobre cohortes de hace 90 o 180 días. Para cuando sabes que la cohorte de junio falló, la empresa ya ha gastado su presupuesto de adquisición de agosto. Las métricas de primeros días, en cambio, se pueden observar en tiempo real y, sobre todo, se pueden correlacionar con la cohorte exacta que está entrando hoy. Eso convierte al diagnóstico en una operación continua, no en una autopsia trimestral.

Los dashboards de churn deberían relegarse a confirmación de hipótesis. La vigilancia real está en el comportamiento del día 1 al día 7. No necesitas esperar a que una cohorte complete su ciclo de vida para saber si tu onboarding funciona: la señal te la da la primera semana de cada nuevo signup.

---

El Churn Como Síntoma, No Como Causa

Vamos a desmontar el mito con señales conductuales concretas. Estas son las firmas de un mapa equivocado — y ninguna aparece en tu dashboard de churn:

❌ Usuarios que completan todo el setup pero nunca ejecutan la acción core. Hicieron todos los pasos del checklist. Importaron datos. Conectaron cuentas. Y nunca usaron la feature central. No es pereza: es que el mapa los llevó a un destino que no era el valor.

Este es quizá el patrón más engañoso porque activa todas las métricas de "éxito" del onboarding tradicional: completaron el wizard, importaron los datos, conectaron las integraciones. El producto debería estar funcionando. Pero la acción core —la que produce el valor y, por tanto, la retención— nunca ocurre. ¿Por qué? Porque el checklist estaba diseñado para completar pasos, no para producir valor. Cuando diseñas el onboarding como una serie de tareas administrativas, obtienes usuarios que completan tareas administrativas. El valor no estaba en el mapa.

❌ Alta adopción de features periféricas con activación baja de la central. Los usuarios exploran y usan las funciones secundarias porque son fáciles. Nunca alcanzan el momento "aha" porque el camino hacia él no está señalizado.

En SaaS de tamaño medio es habitual que la feature central sea la más compleja de configurar. Las periféricas (ajustes, preferencias, integraciones fáciles) requieren menos contexto y se pueden explorar por curiosidad. El resultado es un usuario "activo" que en realidad nunca ha vivido el valor. Si tu dashboard de engagement muestra sesiones frecuentes pero tu activación de la feature core no sube, tienes un mapa que conduce a los pasillos del edificio pero no a la sala principal.

❌ Sesiones que parecen productivas pero no convergen al aha moment. El usuario pasa tiempo en el producto, hace clicks, configura cosas... y aun así no activa. El producto parece funcionar. El mapa no.

Este patrón es el más difícil de detectar porque no hay un fracaso evidente. No hay errores técnicos, no hay usuarios bloqueados, no hay rage clicks. Simplemente, la energía se dispersa. El usuario explora, juega, configura... y se va sin haber cruzado el umbral del valor. En estas sesiones el tiempo de interacción es alto pero el progreso hacia la activación es nulo.

✅ El diagnóstico correcto: estas firmas conductuales revelan el desajuste antes de que el churn lo confirme. Cada una apunta a un punto exacto donde el mapa se desvía del valor real.

La clave de estas tres firmas es que todas son observables en una herramienta de analítica de producto estándar (Mixpanel, Amplitude o PostHog) sin gran complejidad técnica. Solo necesitas tener definido el evento de activación —del que hablaremos en el Paso 4— y segmentar el comportamiento por tipo de usuario. Si ves cualquiera de las tres firmas en los primeros 7 días, el diagnóstico no está en duda: el mapa apunta a otro sitio que no es el valor.

---

El Mapa Correcto Depende de Tu Modelo de Crecimiento

El desajuste más común no está en el onboarding en sí. Está entre tu modelo de crecimiento y tu diseño de onboarding. Funciona así:

En un modelo PLG (Product-Led Growth): el valor debe alcanzarse en auto-servicio antes de pedir cualquier compromiso. El onboarding tiene que conseguir que el usuario vea el "aha" sin hablar con nadie. Si pones un paywall o pides datos demasiado pronto, rompes el mapa.

En PLG el producto es, simultáneamente, el canal de adquisición, la demo y el vendedor. El usuario aterriza, se registra solo, y debe llegar al valor en minutos o en esa primera sesión. Cualquier fricción —un formulario de 8 campos, una demo requerida, un paywall prematuro— no es un inconveniente menor: es un desvío del mapa que puede costarte el usuario entero. En este modelo, el time-to-value no es una métrica a optimizar: es la columna vertebral del negocio.

En un modelo Sales-Led: el onboarding puede y debe usar intervención humana. Puedes sacrificar velocidad a cambio de cualificar mejor al cliente. Tu mapa puede incluir llamadas, demos y asistencia humana desde el día 1 — el time-to-value será más largo, y eso es correcto.

En Sales-Led el valor no tiene que ser inmediato. Lo que importa es que el cliente enterprise se sienta acompañado, que el caso de uso esté bien definido y que la implementación sea guiada por una persona. Aquí, un onboarding 100% auto-servicio y frío no es eficiencia: es abandono. El mapa correcto incluye a los humanos como feature del producto. La cualificación cuenta más que la velocidad.

Los desajustes típicos que matan el mapa:

→ Paywalls o pedidos de datos demasiado tempranos en un producto PLG. Matas la activación antes de que el valor exista.

→ Flujos de auto-servicio fríos en segmentos enterprise que necesitan guía humana desde el día 1. El mapa los deja solos donde necesitan a una persona.

→ Un mapa único para todos: tu early adopter técnico y tu cliente mainstream no comparten el mismo día 1. Uno quiere poder, el otro quiere sencillez. Un solo mapa no puede servir a ambos.

Este último punto merece atención especial porque es el más frecuente en la práctica. Cometes el error de diseñar el onboarding para el usuario que tienes en mente —normalmente, el más parecido a ti— y luego te sorprendes de que la mitad de tus señales de comportamiento no cuadran. La razón es sencilla: no existe "el usuario" de tu SaaS. Existe una distribución de usuarios con expectativas y niveles de madurez distintos, y cada uno necesita un camino distinto hacia el valor. Un único mapa no es neutral: sesga hacia un segmento y abandona a los demás.

Aquí conecta una lección importante del mundo del emprendimiento: el Product-Market Fit crea el despegue, pero el ajuste estratégico —incluido el del onboarding con el modelo de crecimiento— crea la permanencia. Muchos productos SaaS consiguen tráfico y registros (product-market fit superficial) pero fracasan en convertir ese interés inicial en retención. El ajuste estratégico del onboarding es justamente el puente entre el momento del registro y la dominación del mercado.

---

El Patrón de los 7 Días: Diagnóstico y Corrección en un Solo Marco

He usado este proceso en cada SaaS que he construido — desde gestorías en España hasta herramientas B2B. Lo llamo El Patrón de los 7 Días. Va así:

Paso 1: Audita el comportamiento de los primeros 7 días antes de mirar el churn

Deja de mirar el churn como primera métrica. Abre tu analítica de producto — Mixpanel, Amplitude o PostHog funcionan — y mira:

→ ¿Dónde se desvían los usuarios del camino esperado?

→ ¿Qué features ignoran sistemáticamente por segmento?

→ ¿Alcanzan el evento "aha" definido, y en cuánto tiempo?

La idea es reconstruir el viaje real de cada cohorte semanal desde el registro hasta el día 7, sin las gafas del diseño ideal. Pregúntate, para cada paso del onboarding: ¿qué porcentaje de usuarios llega al siguiente paso? ¿Dónde cae la curva de forma pronunciada? Una caída brusca del 60% al 20% entre el paso 2 y el paso 3 es una señal inequívoca de un desajuste localizado.

Paso 2: Declara explícitamente tu modelo de crecimiento

Nada de híbridos difusos. Escribe la regla: en este producto, el valor se alcanza en auto-servicio antes de cualquier compromiso (PLG) o el onboarding usa intervención humana para cualificar (Sales-Led). Ahora compara el onboarding con esa regla.

Este paso parece de trámite, pero es donde la mayoría de los equipos se bloquean. Declarar el modelo por escrito obliga a tomar decisiones incómodas: si eres PLG pero tu equipo de ventas insiste en cualificar leads antes del registro, tienes un conflicto estratégico no resuelto que se manifestará en el día 1. El onboarding no tiene un "problema de UX": tiene un problema de estrategia no decidida.

Paso 3: Diseña mapas por segmento y por madurez

Tu early adopter técnico no quiere un wizard explicando conceptos básicos. Tu cliente mainstream no quiere un formulario con campos avanzados. Segmenta el día 1:

→ Segmento técnico: mapa mínimo, acceso temprano al poder.

→ Segmento mainstream: guía paso a paso, sin asumir jerga.

Cómo hacerlo en la práctica: captura una única señal de segmentación al inicio del onboarding —rol, tamaño de empresa, o quizás simplemente una pregunta de "¿qué quieres hacer aquí?"— y ramifica los siguientes pasos. No necesitas segmentación sofisticada basada en machine learning. Necesitas dos (o tres) caminos bien diseñados en lugar de uno genérico mal diseñado para todos.

Paso 4: Define el evento de activación por segmento

El "aha moment" no es universal. Defínelo por segmento y mide el time-to-value como indicador líder. Compáralo contra el punto esperado de abandono.

Un error habitual es definir la activación como "completar el registro" o "crear el primer proyecto". Eso no es activación: es administración. La activación debe ser el evento que, cuando ocurre, correlaciona estadísticamente con la retención a 90 días. Para descubrirlo, haz un análisis retroactivo de las cohortes que sí retuvieron y busca el evento común que todas ejecutaron en su primera semana. Ese evento, y no el que te parece intuitivo, es tu evento de activación real.

Paso 5: Crea el bucle de corrección

Cuando el comportamiento revele desajuste — setup completado pero acción core nunca ejecutada — realimenta el diseño del onboarding y la segmentación. No te limites a pulir la UX: pregunta si el mapa en sí es el correcto.

El bucle de corrección debe ser un ritual recurrente, no una reacción a crisis. Propón una cadencia sencilla: cada viernes, revisa las métricas del Patrón de los 7 Días de la cohorte de la semana anterior. Si aparece una de las tres firmas de desajuste, dedica la siguiente semana a rediseñar el paso del mapa donde ocurre la desviación. Así el onboarding deja de ser un proyecto puntual y se convierte en un sistema de mejora continua alineado con la estrategia.

---

Respondiendo a Tus Objeciones

"Nuestro problema no es el onboarding: es el pricing o la competencia."

No te estoy acusando de UX. Te estoy diciendo que el onboarding es donde el desajuste estratégico modelo-segmento se hace visible primero. Si el mapa es correcto, tus demás palancas — pricing, product-market fit — operan sobre usuarios que ya alcanzaron el valor. Sin eso, todas las demás palancas empujan en vacío.

Piénsalo así: nadie discute que el pricing o la competencia importan. Pero estás intentando arreglar el techo de una casa cuyos cimientos se están desmoronando. Un usuario que nunca alcanzó el valor no te puede dar feedback útil sobre el pricing —su opinión está contaminada por la falta de valor. Un usuario que sí vivió el aha moment y aun así se queja del precio es un dato accionable. Lo primero es asegurarte de que el mapa lleva al valor. Solo entonces puedes evaluar si el precio o la competencia son realmente el problema.

"Mejorar la UX sí funcionó: subimos la activación con tooltips y checklists."

Las ganancias tácticas sobre un mapa equivocado tienden a estancarse. Mejoraste la legibilidad del mapa, no el mapa en sí. La pregunta no es si la activación subió esta semana: es si la mejora persiste a los 60 días y si ataca el desajuste de fondo.

Hay un fenómeno bien documentado en los equipos de producto: las mejoras de superficie (tooltips, microcopy, color de botones) producen subidas de activación a corto plazo que se desvanecen al cabo de las semanas. El motivo es que no afectan al destino: solo hacen que sea más fácil caminar hacia un punto que no es el valor. Si la activación sube pero la retención a 60 días no se mueve, lo que has hecho es acelerar a los usuarios hacia el mismo lugar equivocado.

"Mi modelo es híbrido (PLG + Sales-Led). ¿Dónde queda el mapa?"

En los híbridos el riesgo de desajuste es máximo. La respuesta es definir reglas explícitas: ¿en qué punto toma el relevo la intervención humana? ¿Qué condiciones marcan el paso de auto-servicio a Sales-Led? Y validar esas reglas con comportamiento de los primeros días — no con churn. El churn te lo dirá demasiado tarde.

El modelo híbrido es legítimo —muchos SaaS B2B lo usan con éxito— pero exige una coreografía más precisa que los otros dos. Necesitas responder a preguntas como: ¿qué evento de bajo valor en auto-servicio activa el trigger para una llamada comercial? ¿Qué umbral de usage score convierte a un usuario en candidate para un sales rep? Cada respuesta implica un punto concreto del onboarding donde el mapa cambia de mano. Si esas reglas no están escritas, el híbrido se convierte en una tierra de nadie donde el usuario no sabe si le van a vender o a acompañar.

---

La Lección: El Mapa es la Estrategia, no la UX

El onboarding es el punto donde la estrategia se convierte en experiencia. Si tu modelo de crecimiento es PLG, tu onboarding debe regalar el valor antes de pedir nada. Si es Sales-Led, debe usar los humanos como feature. Y si tienes segmentos distintos, debes dibujar mapas distintos.

Fíjate en la asimetría que esto revela: el equipo de producto tiende a tratar el onboarding como un problema de diseño, cuando en realidad es un problema de estrategia con consecuencias de diseño. El diseño (tooltips, checklists, tours) es la capa de presentación del mapa. Pero el mapa en sí —dónde empieza, dónde lleva, qué desvíos elimina y cuáles permite— es una decisión de negocio. Confundir ambas capas es el error que asegura que seguirás puliendo la presentación de un mapa equivocado.

El churn es una señal de confirmación, no de diagnóstico. El diagnóstico está en el comportamiento de los primeros 7 días. Deja de pulir tooltips sobre un mapa que apunta al destino equivocado — redeséñalo primero.

Para cerrar, cuatro comprobaciones que puedes hacer mañana mismo:

1. ¿Tienes definido el evento de activación por segmento, o un único evento global? Si es lo segundo, empieza por ahí.

2. ¿Sabes qué porcentaje de tu última cohorte completó el setup pero nunca ejecutó la acción core? Si la respuesta es "no lo sé", tienes tu primera tarea de auditoría.

3. ¿Puedes escribir en una frase tu regla de modelo de crecimiento? Si necesitas más de una frase o te contradices, el desajuste estratégico ya está operando en tu día 1.

4. ¿Tu última mejora de onboarding cambió la legibilidad del mapa o el mapa en sí? Si fue lo primero, no esperes que la retención se mueva.

La cifra del 73% viene citada en la industria sin una fuente primaria unificada. Atribúela con cautela. Pero no necesitas la estadística para ver la lógica: construye el mapa correcto, alinea el day-1 con tu modelo de crecimiento y tu segmento, y el churn dejará de ser un misterio imposible de diagnosticar.

El time-to-value no se optimiza. Se diseña. Y el diseño empieza antes del primer login — empieza en la estrategia.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Tu agente no falla porque el modelo sea tonto. Falla porque razona en una sola pasada y sin nadie que le revise el trabajo.

La gente te dice dos cosas. Primera: "el modelo no es suficientemente inteligente, esperemos al siguiente más grande". Segunda: "chain-of-thought YA es razonamiento".

Ambas son falsas.

*Una traza de chain-of-thought es un monólogo interno.* Un monólogo es serial y auto-confirmatorio: no puede detectar su propia contradicción porque nunca confronta su plan con el mundo.

El razonamiento en un agente no es generar texto. Es un bucle que confronta un plan con resultados reales de tools, invariantes y restricciones — y se corrige. Ese bucle deliberativo es lo que separa un agente que planifica de uno que alucina. Y no necesitas un modelo más grande para construirlo: necesitas arquitectura.

Aquí está el dato incómodo, dicho con transparencia: en producción, he observado que la mayoría de fallos de planificación vienen de una arquitectura de prompting pobre — concretamente, la ausencia de bucles deliberativos con verificación — no de los límites de capacidad del modelo. Lo llamo observación de producción, no estadística publicada, porque no hay un estudio revisado por pares detrás. Pero los mecanismos que lo explican sí se miden: la tasa de divergencias plan-vs-resultado, el número de retries sin verificación, el coste de fallar tarde.

Y hay otro dato que sí podéis comprobar: el 90% de los sistemas "multi-agente" en producción son un único LLM instanciado varias veces con prompts distintos. Sin jerarquía. Sin contratos de datos. Sin validación cruzada. Es un modelo en gabardina disfrazado de equipo.

Cuando alguien os diga que "el agente A supera al agente B", a menudo estáis comparando variantes de prompt del mismo modelo. La capacidad percibida es arquitectura de prompting.

Por Qué el 95% No Es una Exageración (Y Qué es Honestamente una Hipótesis)

Vamos a ser claros sobre qué es qué.

El 95% es una hipótesis de trabajo basada en años de construir agents en producción, no un dato revisado por pares. Tratadla como tal. Pero el mecanismo detrás sí es verificable, y os lo demuestro con código en un momento.

El 90% de los sistemas multi-agente sin contratos de datos ya sabéis que es cierto porque lo veis en vuestras propias codebases: llamáis al mismo modelo con tres system prompts distintos y lo llamáis "arquitectura multi-agente". Cuando los agentes no comparten un schema validado, el agente B recibe la salida del agente A sin verificar. Es el mismo modelo cometiendo los mismos errores en paralelo. Escalar eso no mejora nada: multiplica el ruido.

La implicación práctica es contraintuitiva y molesta para la industria: podéis mejorar agentes de planificación hoy mismo con los modelos actuales añadiendo bucles de verificación. No necesitáis esperar al LLM más grande.

El Enfoque Que Falla: La Pasada Única Auto-Confirmatoria

Empecemos con el ❌ enfoque que casi todos usáis. Un único prompt que genera plan y ejecuta tools en el mismo turno:

```python

❌ Single-pass: plan + ejecución en el mismo prompt, sin artefacto intermedio

def naive_agent(query: str):

prompt = f"""

Objetivo ambiguo: {query}

1. Genera un plan paso a paso.

2. Ejecuta las tools necesarias.

3. Devuelve el resultado final.

Piensa en voz alta (chain-of-thought).

"""

El LLM genera plan Y ejecuta en el mismo turno

return llm(prompt, tools=TOOLS)

```

¿Qué pasa aquí? El modelo genera una traza lineal. En el paso 2, predice que la tool va a devolver `{"status": "ok", "rows": 42}`. Ejecuta la tool real y devuelve `{"error": "timeout", "rows": 0}`. ¿Y qué hace el agente? Nada. No lo detecta, porque la verificación nunca ocurrió.

¿Por qué? Porque CoT de una pasada NO es un bucle deliberativo. Es una traza lineal que se auto-confirma. La traza nunca confronta su plan con el resultado real de la tool. Ese es el fallo típico, y es reproducible con cualquier modelo actual.

El Bucle ReAct Manual: Razonamiento Como Confrontación, No Como Traza

Ahora el ✅ enfoque. Un bucle ReAct manual, sin framework, con condición de parada explícita y comparación lado a lado contra la versión single-pass:

```python

✅ Deliberative loop: plan → ejecuta → observa → verifica → decide

def deliberative_agent(query: str, max_iterations: int = 5):

plan = generate_plan(query) # Fase 1: plan separado

validate_plan_schema(plan) # Fase 2: contrato de datos

for i in range(max_iterations):

result = execute_step(plan[i]) # Fase 3: ejecutar

Fase 4: verificación — el crítico

verification = verify_step(

plan=plan[i],

expected=plan[i]["expected"],

actual=result

)

if verification.passes: # Fase 5: condición de parada verificable

continue

Reflexión: revisa el plan, no improvises

plan[i:] = revise_plan(

plan=plan[i:],

evidence=verification.failure_reason,

constraints=CONSTRAINTS

)

return plan

```

Mirad el log de ambos y veréis dónde diverge la traza lineal del bucle deliberativo:

```

[NAIVE] Paso 2: "La tool devuelve 42 rows" → tool devuelve 0 rows → agente no lo detecta

[NAIVE] Resultado final: 42 rows (inventados)

[LOOP] Paso 2: "La tool devuelve 42 rows" → tool devuelve 0 rows → VERIFICACIÓN FALLA

[LOOP] Crítico: timeout detectado. Revisando plan...

[LOOP] Paso 2 revisado: retry con backoff → 42 rows reales

[LOOP] Resultado final: 42 rows (verificados)

```

El loop no es un gasto de tokens. Es la función de evaluación que la pasada única no tiene. El razonamiento vive en la verificación: generar sin discriminar es solo muestreo.

Técnicas Que ya Comprueban Esto (Si las Usáis Como Bucles, No Como Prompts)

Esto no es teoría. Reflexion, Self-Refine y self-consistency comparten exactamente el mismo patrón: añadir un discriminador al generador. El problema es que casi todo el mundo los implementa como "prompt de turno extra" en lugar de "punto de control con verificación".

• Reflexion: el modelo recibe retroalimentación verbal sobre su intento fallido antes del siguiente. Eso es un discriminador hablándole al generador.

• Self-Refine: el modelo produce, luego *crítica su propia salida contra criterios, luego corrige. Críticar no es opcional*: es el paso donde el razonamiento ocurre.

• Self-consistency: muestreáis varias trazas y votáis. Cada traza es un candidato de descomposición; la votación es la selección contra restricciones.

La descomposición de un objetivo ambiguo en un plan concreto no es un problema de generación: es un problema de búsqueda. El agente debe generar candidatos de descomposición y seleccionarlos contra restricciones. Una pasada única no puede hacerlo porque se compromete con la primera descomposición que genera.

El Bucle Deliberativo de 5 Fases para Planning de AI Agents

Aquí está el framework. Lo llamo El Bucle Deliberativo de 5 Fases, y es lo que he enviado a producción en projects reales — desde herramientas para autónomos españoles hasta sistemas para asesorías y gestorías.

Fase 1 — Genera el plan como artefacto, no como texto de relleno.

Genera primero un plan explícito, validado contra un JSON Schema. Ejecuta después. Nunca generes plan y ejecutes en el mismo prompt: sin artefacto intermedio no hay nada que verificar.

```python

from pydantic import BaseModel, Field, ValidationError

class PlanStep(BaseModel):

action: str

tool: str

params: dict = Field(...)

expected: dict # ← lo que el plan PROMETE que pasará

invariants: list[str] # ← restricciones del mundo (rangos, formatos)

class Plan(BaseModel):

steps: list[PlanStep]

goal: str

def validate_plan_schema(plan: dict) -> Plan:

try:

return Plan.model_validate(plan)

except ValidationError as e:

raise PlanValidationError(e) # ← el agente NUNCA sigue un plan inválido

```

Fase 2 — Contratos de datos entre cada paso.

Ningún paso recibe salida no validada. Esto es la validación cruzada que el 90% de los sistemas multi-agente no tienen. Si el agente B recibe la salida cruda del agente A, estáis corriendo el mismo modelo con los mismos errores en paralelo.

Fase 3 — Ejecuta una acción, una tool call, aislada.

Un paso, un resultado observable.

Fase 4 — Un crítico verifica contra el plan y las restricciones.

Puede ser el mismo modelo con rol distinto, un modelo más barato, o validadores deterministas (Pydantic contra invariantes del mundo: formato, rangos, referencias cruzadas). "El hilo piensa en voz alta, pero con alguien que revise."

Fase 5 — Condición de parada VERIFICABLE, no presupuesto de tokens.

Repite plan → ejecuta → verifica → revisa hasta que el verificador pase, no hasta agotar tokens. Si no hay criterio de parada verificable, no es un bucle deliberativo: es un gasto de tokens en bucle.

El Presupuesto de Inferencia ES el Diseño

Ahora la objeción que estáis pensando: "los bucles de reflexión duplican tokens y latencia; inviables en producción."

Respuesta: la verificación no tiene que ser cara.

• Un modelo pequeño como verificador en puntos críticos del plan.

• Validadores deterministas con Pydantic para invariantes mecánicas.

• Verificación solo en los pasos de riesgo, no en todos.

Y lo más importante: el coste de retry sin verificación suele superar al del verificador. Fallar tarde — después de ejecutar acciones sobre un plan erróneo — es mucho más caro que un modelo barato que detecta la divergencia antes de continuar. Es medible con tracing (LangSmith o Weave sirven) logueando divergencias plan-vs-resultado y la tasa de revisiones que el loop necesita.

El dinero gastado en modelos más grandes está mal asignado si el bucle de verificación no existe. Un modelo barato con un verificador puede superar a un modelo grande en single-pass. Es un patrón observado en producción, no un benchmark publicado — pero podéis medirlo en vuestro propio sistema esta semana.

Qué Hacer Ahora: El Diagnóstico que Te Dice Dónde Invertir

Instrumenta y mide. Loguea divergencias plan-vs-resultado y la tasa de revisiones que el bucle necesita. Aquí está la regla de oro:

Si el bucle no mejora la tasa de éxito, el problema no es el planificador — es el verificador.

Ese diagnóstico os dice exactamente dónde gastar el presupuesto de inferencia. ¿Divergencias altas y el crítico no las detecta? Mejorad el crítico (constrained, mejor prompt, determinista). ¿El crítico detecta pero el planificador no corrige bien? Mejorad la revisión. ¿Ninguna divergencia? Tenéis un agente trivial que no necesitaba el bucle.

Herramientas concretas: LangGraph para grafos con checkpoints y loops (el checkpoint es lo que hace el estado explícito entre pasos), Pydantic para contratos de datos, y LangSmith/Weave para tracing de divergencias.

La Verdad Incomoda: CoT Es el Material en Bruto, No el Razonamiento

Decidme si esto os suena: "probé chain-of-thought y mi agente sigue fallando; el modelo no es lo bastante inteligente."

No. El problema es que tratasteis CoT como si fuera el razonamiento completo. CoT es el material en bruto del razonamiento. El razonamiento es el bucle.

Una traza de chain-of-thought muestra el monólogo interno del modelo. Pero un monólogo es serial: nunca confronta el plan con el mundo porque nadie se lo pide. El bucle deliberativo fuerza esa confrontación con resultados reales de tools. Esa confrontación es lo que en los agents merece llamarse razonamiento.

La próxima vez que vuestro agente falle, no miréis el modelo. Mirad el bucle. Si no hay verificación, no hay razonamiento — solo texto generado con confianza.

El patrón está claro: el agente que planifica de verdad no es el que produce el mejor monólogo. Es el que se corrige cuando su plan choca con la realidad. Empezad por ahí, con los modelos que ya tenéis, y dejad de esperar al LLM que os va a salvar del mal prompting.

No vais a llegar al primer millón esperando a que el siguiente modelo razone por vosotros. Vais a llegar construyendo el bucle que verifica lo que ya generáis hoy.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Crees que tu problema es el churn. Que sube en el dashboard, que el logo churn es un pozo, que necesitas mejores flujos de activación, mejor NPS y mejor soporte. Que si arreglas el onboarding, el segmento se queda.

*Te has equivocado de diagnóstico.*

El churn no es la enfermedad. Es el síntoma tardío. Y el 73% de los SaaS no fracasa por tener churn alto: fracasa por tratar su modelo de crecimiento como una decisión permanente, casándose con PLG o con Sales-Led y negándose a adaptarlo cuando deja de encajar con sus segmentos de cliente. El dato no habla de tasas de churn. Habla de rigidez estratégica.

Y por eso tus dashboards de churn, tus cohortes por fecha de alta y tus exit surveys genéricas llevan meses apuntando al producto cuando el verdadero culpable es el desajuste entre cómo vendes y a quién le vendes.

🔍 Cómo descubro el desajuste que nadie mide: en mis productos (conversoriaecnae.es, gestoriascercademi.com, findemergencyplumber.com) el patrón se repite: el churn que parece de producto casi siempre es de motion. Un cliente que compró por autoservicio pero necesitaba onboarding guiado no falla por tu feature set. Falla porque el modelo con el que lo adquiriste no encaja con su segmento.

---

Pongamos un ejemplo concreto para que esta idea no quede en el aire. Piensa en un SaaS de gestión documental para despachos de abogados. Lanzas un plan self-serve de 29 € al mes y lo apuntas a pequeñas firmas independientes. Todo parece razonable: el precio es bajo, la configuración es trivial, puedes activarlo en una tarde. Tres meses después, el churn de ese segmento ronda el 8% mensual. Tu primera reacción es mirar el onboarding: "quizá los flujos de bienvenida no empujan suficiente valor". Rediseñas el onboarding, lanzas un email sequence nuevo, mejoras el empty state. El churn no se mueve ni un punto.

Lo que no has mirado es el motion: ¿ese abogado independiente que pagó 29 € esperaba realmente configurarlo solo? ¿O le prometió tu página de ventas una "implementación asistida sin coste" mientras por el otro lado empujabas el autoservicio? Cuando segmentas esa cohorte por el canal que la trajo — no por el mes de alta — descubres que el 9% de la fuga viene de cuentas que llegaron por un webinar de venta consultiva. Compraban con la expectativa de una mano guiada. Recibieron un producto que les pedía "explorar por su cuenta". Ese cliente no falló por tu producto: falló por el contrato tácito roto entre cómo lo vendiste y cómo lo entregaste.

Por Qué Esto se Confunde Tan Fácilmente con un Problema de Producto

La razón por la que el desajuste de motion se disfraza de problema de producto es sutil. Cuando un cliente no se activa, tu telemetría de uso muestra exactamente lo mismo que mostraría con un onboarding deficiente: pocos logins, funciones clave sin tocar, breve tiempo de sesión. Desde fuera, los datos sanguíneos del producto son idénticos. Solo cuando cruzas esa telemetría con la variable motion aparecen dos realidades distintas conviviendo bajo la misma curva de uso.

Ese es el core del problema que aborda este artículo: tu dashboard te dice dónde duele, pero no qué lo causa. Para saberlo necesitas añadir una dimensión que casi ningún dashboard SaaS estándar contempla: el movimiento de mercado con el que adquiriste a cada cohorte.

---

Por Qué los Dashboards de Churn Mienten

El churn promedio es una mentira estadística. Puro sesgo de agregación.

Si un segmento churnea al doble que otro, promediar ambos en una sola métrica hace desaparecer el indicador adelantado en el ruido. El equipo mira el número global, ve que "está estable", y sigue optimizando onboarding para siempre mientras un segmento entero se fuga en silencio.

❌ El enfoque convencional: dashboards con churn mensual agregado, cohortes por mes de alta, exit surveys con "¿por qué te fuiste?" y opciones (precio, competencia, falta de uso).

✅ El enfoque que funciona: cohortes segmentadas por motion de adquisición, no solo por fecha. Compara por separado la retención de tus cohortes self-serve (PLG) contra tus cohortes sales-assisted.

Si una cohorte churnea al doble que la otra, el problema es de modelo, no de producto. Y eso cambia absolutamente todo el plan de acción.

El Sesgo Que Esconde la Causa Real

Piénsalo conmigo. Adquieres un cliente enterprise con un ciclo de venta largo de tres meses. Lo cierras, entra en tu dashboard. Al mes siguiente, su activación está por los suelos. ¿Qué dice el dashboard? "Problema de onboarding."

Qué dice la realidad: adquiriste a un cliente enterprise con un motion self-serve. Espera autoservicio, clicks y self-onboarding. Pero el sales-assisted que lo cerró le prometió onboarding guiado, éxito dedicado y migración asistida. Ese cliente no necesita mejor onboarding: necesita el motion con el que lo vendiste.

Un SMB forzado por un ciclo de venta largo es el mismo desajuste al revés. Compra un SaaS barato que esperaba configurar en una tarde y de repente tiene proceso de compra con demostraciones y vendor manager. Churn inevitable.

Ninguna de esas fugas es producto. Las dos son motion mismatch.

El Precio de Seguir Solo la Média Agregada

El sesgo de agregación no solo oculta el problema: lo retroalimenta. Cuando promedias el churn de un segmento self-serve sano con uno sales-assisted enfermo, obtienes un número "aceptable". Ese número te da permiso para no actuar, o peor, para actuar en la dirección equivocada. Optimizas el onboarding que ya funcionaba en la cohorte sana, ignoras al segmento en fuga y, mientras tanto, sigues adquiriendo clientes con el motion equivocado para su perfil. Seis meses después, el segmento enfermo es el doble de grande y la fuga silenciosa se convierte en una hemorragia imposible de ignorar.

El churn promedio no es solo inútil: es activamente dañino, porque convierte tu principal sistema de alerta temprana en un tranquilizante estadístico.

---

El Framework: El Protocolo de Motion Mismatch

El Protocolo de Motion Mismatch (PMM) es el método para diagnosticar el churn por su causa raíz real. Cuatro pasos medibles, no filosofía.

Antes de entrar en los pasos, una aclaración importante sobre el espíritu del método. El PMM no pretende sustituir a tu análisis de producto ni a tus procesos de customer success. Lo que hace es añadir una capa de diagnóstico que hoy no existe: separar el fracaso de producto del fracaso de motion. Sin esa separación, cualquier inversión en el producto (onboarding, features, soporte) puede estar bien ejecutada y, sin embargo, ser completamente inútil, porque está tratando el síntoma equivocado.

Paso 1: Segmenta por Motion, No por Fecha

Deja de agrupar cohortes por mes de alta. Segmenta por canales de adquisición su movimiento de mercado: PLG/directo vs. sales-led.

En tu tabla de retención, compara el churn de la cohorte que compró self-serve contra la que vino por ciclo de venta. Traza ambas curvas. Si divergen más de un 20-30% al tercer mes, tienes un mismatch de motion. El producto no es el culpable.

¿Cómo implementarlo en la práctica? Necesitas una columna `acquisition_motion` en tu base de datos de clientes. No es difícil de rellenar retrospectivamente: la mayoría de CRM y herramientas de atribución distinguen entre tráfico orgánico directo (self-serve), ciclo de venta con demo (sales-assisted) y canales intermedios (partnerships, marketplaces, recomendaciones). Si no la tienes, asigna la etiqueta por el canal con mayor peso en la atribución del cierre.

A partir de ahí, tu tabla de retención debería tener tres dimensiones: cohort (por fecha), motion (por canal) y retención. Al cruzar estas tres variables aparecen patrones que la vista agregada jamás revela. Por ejemplo, una curva de retención self-serve que se mantiene estable al 90% a los seis meses, mientras la sales-assisted cae al 60%. Si solo mirabas la media, veías un 75% "asumible". Ahora ves un segmento entero en descomposición.

Paso 2: Rediseña la Exit Survey para Aislar la Capa Que Falló

La mayoría pregunta "¿por qué te vas?" y obtiene respuestas genéricas: precio, competidor, "ya no lo uso". Puro ruido.

Rediseñala con dos preguntas que jamás verás en una encuesta de satisfacción de producto:

• "¿Cómo compraste?" (autoservicio, demo guiada, recomendación)

• "¿Qué esperabas al comprar?" (configurarlo solo, onboarding asistido, migración incluida)

Un cliente que eligió self-serve pero necesitaba guía es fallo de motion que jamás aparecerá si solo preguntas por satisfacción. La exit survey deja de ser autopsia y se convierte en triaje.

Diseño de la encuesta: menos es más. No hagas diez preguntas. Dos preguntas de clasificación + una opcional de texto libre es suficiente para el diagnóstico temprano. El objetivo no es entender cada matiz de la insatisfacción del cliente; es clasificar rápidamente la fuga en una de dos categorías: *"consume como esperaba pero no encuentra valor durable" (fallo de producto/propuesta) o "no consume como esperaba porque el journey de compra prometió otra cosa"* (fallo de motion).

La primera categoría te lleva al roadmap de producto. La segunda te lleva a revisar messaging, packaging y proceso de venta. Son caminos de acción tan distintos que no puedes permitirte mezclarlos.

Paso 3: Monitoriza el Uso como Indicador Adelantado

El churn es una métrica lagging: aparece cuando ya es tarde. La tasa de activación y el time-to-value por segmento son leading: avisan antes.

Mide el umbral de activación que históricamente predice retención, y el comportamiento de power user, por segmento. Cuando la activación de un segmento se estanca por debajo de ese umbral durante dos trimestres, esa es la señal más temprana de mismatch de motion — mucho antes de que el churn aparezca en el dashboard.

¿Qué métricas concretas mirar? Tres, en orden de prioridad:

1. Tasa de activación definida: el porcentaje de cuentas nuevas que alcanzan tu "aha moment" en los primeros 14 días. Defínelo por función clave, no por login.

2. Time-to-value: días desde el alta hasta el primer resultado entregado (primera automatización activada, primera factura emitida, primer reporte generado).

3. Ratio de power users: porcentaje de cuentas activas que usan el producto por encima del percentil 80 de uso.

La combinación de estas tres métricas, segmentada por motion, te ofrece un panel de alerta premium a la altura del problema. Si ves un segmento con activación al 20% cuando el umbral histórico que predice retención es el 40%, tienes un aviso de mismatch con meses de antelación. No necesitas esperar a que el churn aparezca en el dashboard para saber que algo estructural está roto.

Triangula tres fuentes: exit surveys, telemetría de uso pasiva y datos de win/loss. No dependas de encuestas con muestras pequeñas. La telemetría no miente.

Un consejo adicional sobre la triangulación: los datos de win/loss son la pieza que más equipos ignoran. Si pierdes deals en la fase final de un ciclo sales-assisted contra competidores que ofrecen "implementación en una semana", está clara la brecha de expectativas que luego pagarás como churn. Esa información existe antes de que el cliente compre; aprender a leerla es aprender a prevenir el mismatch antes de que se materialice.

Paso 4: Define el "Model Switch Trigger" Como Protocolo

Decide ahora, por escrito, qué métrica obliga a reevaluar el motion de forma deliberada. Por ejemplo:

```

DISPARADOR: tasa de activación del segmento S por debajo del 35%

durante dos trimestres consecutivos, con un churn proyectado > 3% mensual.

ACCIÓN: junta de gobernanza trimestral que revisa el motion de ese segmento,

con data (cohortes por motion) sobre la mesa. Switch puede ser híbrido.

```

El switch no es binario. Puede ser gradual: un motion híbrido que añade onboarding guiado como add-on, un tier de precio con éxito dedicado, un lead magnet que filtra el segmento correcto. No es un volantazo, es un ajuste de rumbo.

La clave del paso 4 es la anticipación. Si defines el trigger cuando ya estás en crisis, el miedo a lo desconocido y la presión del momento nublan el juicio. Definirlo con calma, con datos sobre la mesa y sin un incendio ardiendo, convierte una decisión política y emocional en un procedimiento operativo estándar. La gobernanza por trigger elimina la discusión "¿es un problema de producto o de ventas?" — una discusión que, en la práctica, casi nunca se resuelve por méritos, sino por la influencia política de los departamentos implicados.

Para que el proceso funcione, el trigger debe cumplir tres criterios:

• Medible sin ambigüedad: "activación por debajo del 35%" funciona. "El equipo siente que algo va mal" no.

• Con plazo definido: un trimestre de datos malos puede ser ruido; dos son una tendencia.

• Con consecuencias pre-acordadas: el trigger no solo alerta; dispone una junta de gobernanza con autoridad para cambiar el motion.

---

El Silent Downgrade: La Fuga Que Nadie Ve

Hay un análisis que casi nadie hace: el silent downgrade. Separar las cancelaciones reales de las cuentas que bajan de plan o simplemente dejan de expandir.

La pérdida silenciosa de expansión — cuentas que se quedan pero no crecen — suele indicar mismatch de modelo: el cliente se queda porque ya pagó el ciclo, pero no encuentra suficiente valor para expandir. La cancelación dura apunta más a fallo de producto.

Dos fugas distintas. Dos diagnósticos opuestos. Un solo dashboard de churn las mezcla y te obliga a adivinar.

¿Por qué es tan fácil perder de vista el silent downgrade? Porque no activa ninguna alerta. El cliente no se va, no abre un ticket, no contesta la exit survey (porque no hay). Simplemente permanece en tu base de ingresos, pagando lo mismo, sin pedir nada. Desde la perspectiva de un dashboard de churn clásico, es un cliente sano. Desde la perspectiva del revenue expansion, es una cuenta que se ha apagado emocionalmente y que muy probablemente cancelará en el próximo ciclo de renovación — salvo que alguien intervenga antes.

La señal más temprana del silent downgrade suele ser el comportamiento de uso: sobre todo, la caída progresiva de logins activos y la desactivación de funciones clave. Cuando ves ese patrón en una cuenta que no ha cancelado, tienes delante a un cliente en cámara lenta. Puedes intervenir con un motion correcto (onboarding asistido, revisión trimestral, éxito dedicado) o puedes esperar a que la cancelación llegue al dashboard. El PMM te da la herramienta para elegir lo primero.

---

Las Objeciones Que Vas a Poner

"Cambiar de modelo de crecimiento es demasiado caro."

Claro que lo es. Pero el framework es primero un diagnóstico. Si segmentas por motion y la activación baja de forma uniforme en todas las cohortes, el producto es el culpable — el framework valida esa conclusión si las cohortes están segmentadas por motion y no solo por fecha. Si solo falla un motion, arreglar onboarding es tratar el síntoma mientras el segmento entero se fuga.

"Las exit surveys están sesgadas, solo responden los enfadados."

Cierto. Por eso el PMM triangula con telemetría de uso pasiva y datos de win/loss. En cuentas enterprise con pocos logos, apoyas en análisis cualitativo por cuenta y patrones de uso a nivel de account, no en tests estadísticos de cohortes.

"Cambiar de motion toca compensación comercial, staffing de onboarding, packaging de precios."

Exacto. Ese es el motivo exacto por el que las empresas lo evitan: el switch es político, no data-driven. El Protocolo de Motion Mismatch lo convierte en mecanismo de gobernanza: la métrica decide, no el comité. Dejas de discutir opiniones y discutes datos.

La Objeción Más Silenciosa: Ninguna

La objeción más peligrosa a este framework no aparece en las reuniones. Es la de los equipos que escuchan, asienten y luego siguen con su dashboard de churn agregado de toda la vida. No porque no entiendan el argumento, sino porque el cambio requiere reconfigurar pipelines de datos, etiquetar clientes por motion y, sobre todo, aceptar que la métrica que creían entender (churn) no era la métrica que debían vigilar.

Superar esa inercia no es un problema técnico: es un problema de liderazgo. Requiere que alguien con autoridad diga "a partir del próximo trimestre, los cohortes se segmentan por motion en todas las presentaciones de retención". Sin ese momento explícito, el framework se queda como una buena lectura de blog y nada más.

---

El Churn No Se Arregla. Se Diagnostica.

El root-cause analysis solo es útil si el diagnóstico puede cambiar el motion de crecimiento. Si no, cada exit survey confirmará tu sesgo y cada cohorte confirmará tu diagnóstico equivocado. Estarás analizando cadáveres: midiendo la salida, nunca la causa.

Pensemos en la analogía clínica: un médico que solo registra la causa de muerte de sus pacientes no está haciendo medicina preventiva, está escribiendo historias clínicas. De la misma forma, un equipo de producto que solo documenta por qué se van los clientes — sin intervenir sobre la causa estructural — está redactando autopsias, no construyendo retención.

La diferencia entre un dashboard de churn y el Protocolo de Motion Mismatch es exactamente esa: uno describe el pasado, el otro anticipa el futuro. Y en el mercado actual, donde el tiempo de respuesta al desajuste estratégico es la ventaja competitiva más difícil de copiar, llegar tarde a ese diagnóstico tiene un coste que ningún roadmap de producto puede compensar.

El churn no es tu problema más urgente. Tu rigidez estratégica lo es.

Cuando segmentes por motion, aísles la capa que falló, monitorices indicadores adelantados y definas tu model switch trigger como protocolo, dejarás de preguntarte "¿por qué churnea esta gente?" y empezarás a preguntar la única pregunta que importa: ¿estoy vendiendo con el modelo correcto al segmento correcto?

Y esa pregunta, bien respondida, es la diferencia entre medir métricas y construir un producto que se queda.

Para Llevarte a Casa

• El churn es síntoma tardío, no causa. La rigidez del modelo de crecimiento es la causa.

• Segmenta cohortes por motion de adquisición, no solo por fecha.

• Las exit surveys deben preguntar "¿cómo compraste?" y "¿qué esperabas?".

• La activación y el time-to-value son métricas leading; el churn es lagging.

• Define tu model switch trigger como protocolo escrito, antes de necesitarlo.

• Separa silent downgrade de cancelación dura: son dos diagnósticos distintos.

El 73% de los SaaS no fracasa por churn alto. Fracasa por no atreverse a cambiar el modelo cuando los datos gritan. Los datos ya están en tu dashboard. Solo hay que saber dónde mirar.

Y cuando los mires, recuerda una última cosa: el motion con el que empezaste no tenía por qué ser el correcto para siempre. Los mercados cambian, los segmentos evolucionan y lo que funcionó para conseguir tus primeros cien clientes puede ser exactamente lo que ahuyente a los siguientes mil. La pregunta no es si tu modelo de crecimiento es bueno: es si sigue siendo el adecuado para el segmento que estás persiguiendo hoy. Esa es la pregunta que tus dashboards deberían estar respondiendo — y la que casi ningún dashboard estándar responde.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Antes de añadir tu segundo agente, lee esto.

El 90% de los sistemas "multi-agente" que ves en producción no son multi-agente en absoluto. Son un solo LLM instanciado tres veces con prompts distintos. Sin jerarquía. Sin contrato de datos compartido. Sin validación cruzada.

*Y el resultado medible es que 3 agentes mal coordinados funcionan peor que 1 agente bien hecho. *

No es una opinión. Es lo que pasa cuando el acoplamiento entre agentes es frágil y cada handoff multiplica errores en lugar de cancelarlos.

El ecosistema te vende lo contrario. Frameworks, marketplaces y demos empujan la narrativa del "enjambre de agentes": más agentes = más capacidad. Añade un agente de investigación, otro de redacción, otro de revisión, y el resultado debería mejorar, ¿no?

No. No escala así. La capacidad no escala con el número de agentes. Escala el error compuesto — y eso va en tu contra.

El Problema Real No es el Número de Agentes. Es el Acoplamiento Frágil

La causa raíz del fallo en sistemas multi-agente no son los agentes. Es el acoplamiento entre ellos.

Piénsalo. En una cadena de N agentes, la salida de cada uno es la entrada del siguiente. Cada handoff es una oportunidad de amplificar una alucinación. Si el agente A produce un formato ligeramente distinto al que el agente B espera, todo se rompe. Si A inventa un dato, B lo toma como verdad y lo embellece, y C lo escribe en la respuesta final.

Por eso más agentes no escalan linealmente. Cada agente extra añade puntos de acoplamiento y rutas de propagación de errores. No es que los agentes sean malos. Es que cada uno multiplica la superficie de fallo.

Y aquí viene lo incómodo: si tu "multi-agente" es el mismo modelo con prompts distintos pasando texto libre entre sí, no tienes N agentes. Tienes N prompts, N puntos de fallo, y cero capacidad extra.

El problema es un problema de diseño de interfaces. Cada subagente debe tratar su entrada y salida como un contrato de API: esquemas tipados, validación, versionado. Si dejas los handoffs como texto libre, estás definiendo exactamente el acoplamiento frágil que mata a estos sistemas.

El Test de los 3 Elementos: ¿Tu Sistema es Real o es Role-Play?

Antes de tocar una línea de código, audita tu sistema actual contra el test de los 3 elementos. Un sistema multi-agente real tiene los tres:

1. Coordinación real: un planner o state machine que decide quién hace qué y cuándo.

2. Jerarquía: un orquestador que controla el flujo — los workers no hablan entre sí directamente.

3. Validación cruzada: un revisor o chequeo determinista que acepta o rechaza la salida de un worker antes de que propague.

❌ Anti-patrón (lo que hace el 90%): el mismo LLM con prompts distintos. Los agentes se pasan trozos de texto sin schema, sin estado, sin validación. Los errores se compilan a lo largo de la cadena.

✅ Patrón real: un orquestador que planea, despacha con contratos tipados, fusiona resultados, y decide cuándo re-ejecutar o rechazar la salida de un worker.

Si tu sistema no tiene los tres elementos, no tienes agentes. Tienes role-play con puntos de fallo extra.

Aquí tienes el anti-patrón para que lo reconozcas:

```python

ANTI-PATRÓN: el 90% de los "multi-agente" en producción

def mis_sistema_multiagente(tarea: str) -> str:

modelo = get_llm() # el MISMO modelo para todos

Agente "investigador" — solo cambia el system prompt

investigacion = modelo.complete(system="Eres un investigador.",

user=tarea)

Agente "redactor" — recibe texto libre, sin schema

borrador = modelo.complete(system="Eres un redactor.",

user=investigacion) # acoplamiento frágil

Agente "revisor" — valida... contra nada

final = modelo.complete(system="Eres un revisor.",

user=borrador)

return final

3 agentes, 0 jerarquía, 0 contrato, 3 sitios para amplificar errores

```

¿Ves el problema? Tres calls al mismo modelo. Cero esquemas. Cero validación. Si el "revisor" recibe un formato que no espera, falla silenciosamente. Si el "investigador" alucina, el "redactor" lo embellece y el "revisor" lo aprueba.

Ese es el acoplamiento frágil en su forma pura.

¿Los Benchmarks Publicados No Muestran que Multi-Agente Gana?

Sí. Y eso confirma la tesis en lugar de contradecirla.

Los benchmarks que muestran a sistemas multi-agente ganando a un solo agente vienen de setups meticulosamente orquestados: jerarquía, handoffs tipados, validación. Es decir, la coordinación real que los sistemas de producción no tienen.

El benchmark es la prueba. La calidad del resultado no la determina el número de agentes. La determina la calidad de la orquestación.

Y si tu equipo pregunta "¿diferentes prompts no crean efectivamente agentes distintos?" — no. La variación de prompts cambia el comportamiento, no la arquitectura. No hay jerarquía, no hay contrato de estado compartido, no hay loop de validación. Es un modelo haciendo role-play con puntos de fallo añadidos.

La especialización real requiere tres cosas que el role-play no tiene: herramientas distintas, contexto distinto, e una interfaz explícita.

El Marco de las 3 Preguntas del Orquestador

Cuando el multi-agente gana de verdad, es para subproblemas paralelizables e independientes con un paso de fusión — como investigación en varias fuentes más una pasada de revisión — donde un solo agente agotaría su ventana de contexto.

Las tareas secuenciales y dependientes son el peor encaje posible: acoplamiento máximo, paralelismo cero, y todos los beneficios del patrón desaparecen.

Aquí va el Marco de las 3 Preguntas del Orquestador. Antes de añadir cualquier agente extra, respóndelas:

Pregunta 1 — ¿Tengo baseline de un solo agente?

Construye el agente único excelente primero: un modelo, buenas tools, output estructurado. Mídele la tasa de éxito sobre un test set fijo. Cada afirmación multi-agente de tu sistema debe validarse contra este número.

Pregunta 2 — ¿El subproblema es genuinamente independiente?

¿Puede ejecutarse en paralelo sin depender de la salida del otro? Si la secuencia es estrictamente dependiente, un solo agente con tools hace el trabajo sin los puntos de fallo extra.

Pregunta 3 — ¿Tengo contrato tipado y validación?

Cada handoff es un schema tipado (Pydantic, JSON Schema, lo que sea). Workers nunca se pasan texto libre. Y un crítico — o chequeos deterministas — acepta o rechaza contra el plan antes de que propague.

Este es el patrón real, con contrato tipado y validación:

```python

from pydantic import BaseModel

from typing import List, Optional

from enum import Enum

class Subtarea(BaseModel):

id: str

tipo: str # "investigacion" | "redaccion"

instrucciones: str

estado: str = "pendiente"

resultado: Optional[str] = None

validado: bool = False

class Plan(BaseModel):

subtareas: List[Subtarea]

prioridad: List[str]

merge_rule: str = "concurrente"

El orquestador: planea, despacha, fusiona, decide

class Orquestador:

def planificar(self, tarea: str) -> Plan:

Un planner DE DETERMINISTA extrae subtareas

No es otro LLM role-play: es lógica de negocio

return self.splitter.extraer_subtareas(tarea)

def ejecutar(self, plan: Plan) -> dict:

resultados = {}

for sub in plan.subtareas:

worker = self.get_worker(sub.tipo) # herramienta/esquema propio

salida = worker.ejecutar(sub.instrucciones, schema=SchemaEsperado)

Validación cruzada ANTES de propagar

if not self.validador.aprobar(salida, contra=plan):

salida = worker.reescribir(sub.instrucciones, feedback)

resultados[sub.id] = salida

return self.merge(resultados, plan.merge_rule)

jerarquía (orquestador manda), contrato (schemas), validación (aprobar/rechazar)

```

⚠️ Comparación de tools (todas válidas):

• LangGraph: orquestación basada en grafo con estado explícito y edges tipados. El más cercano al patrón jerarquía + contrato.

• CrewAI: crews por roles con control de proceso integrado. Buen punto de partida si no quieres construir el state machine a mano.

• AutoGen: conversacional. Más fácil caer en el anti-patrón de texto libre entre agentes.

• State machine a mano: prefieres el control total. El patrón no depende del framework.

El Paso Más Importante: Mide la Regresión

Aquí está la parte que casi nadie hace.

Construye tu pipeline multi-agente. Ejecútalo sobre el mismo test set fijo que usaste para el baseline de un solo agente. Compara tasas de éxito.

Si el pipeline multi-agente no supera al baseline, reverte. Coordinación solo se justifica con ganancia medida.

Y la predicción incómoda: en muchos casos no la superará. El multi-agente gana solo cuando hay paralelismo real — tareas independientes que un solo agente no puede ejecutar sin agotar su ventana de contexto. Investigación multicanal, análisis de documentos largos con pasada de revisión, generación de contenido con revisión independiente.

Las cadenas secuenciales dependientes — donde cada agente espera la salida del anterior — son cargo cult. El peor encaje posible.

¿"¿Pero no hay tareas que genuinamente necesitan más de un agente?" Sí. El argumento es condicional:

• ✅ Multi-agente justificado: subproblemas paralelos e independientes con paso de fusión. La coordinación está diseñada (contratos, jerarquía, validación) y medida contra el baseline.

• ❌ Multi-agente como cargo cult: cadenas secuenciales dependientes donde los agentes se pasan texto libre. Máximo acoplamiento, cero paralelismo, error compuesto.

La Verdad Incómoda Sobre el 90%

Seamos honestos: la cifra del 90% es una tesis de practicante, no un benchmark medido de la industria. Es una afirmación direccional.

Pero es falsable y barata de testear. Audita tus propios sistemas:

¿Cuántos de tus "agentes" comparten el mismo modelo? ¿Cuántos no tienen paso de validación? ¿Cuántos handoffs son texto libre sin schema?

Si la mayoría — ya sabes la respuesta.

El camino correcto es el que casi nadie sigue: construye UN agente excelente con tools antes de añadir un segundo. Mídelo. Y solo entonces, si el problema es genuinamente paralelo, añade trabajadores con contratos tipados y un supervisor que apruebe o rechace.

La pregunta correcta no es "¿cuántos agentes?". Es "¿dónde está la coordinación?" — y la respuesta incómoda es que la mayoría de los equipos deberían construir un agente excelente antes de soñar con el segundo.

La coordinación no se añade. Se diseña. Y se mide. O no existe.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Crees que la decisión PLG vs Sales-Led es estratégica. Que eliges el modelo correcto, compras el marco mental, y te comprometes hasta el final. Que el foco lo es todo.

*Te has equivocado de diagnóstico.*

El 73% de los SaaS no fracasa por elegir mal el modelo de crecimiento: fracasa por adherirse rígidamente a un único modelo cuando el producto y el mercado evolucionan. La rigidez de identidad — *"somos una empresa PLG"* — sobrevive a los datos que la justificaron.

Igual que una feature muerta sobrevive en tu roadmap por haber sido pedida una vez, un modelo de crecimiento caducado sobrevive porque cambiar de identidad da miedo.

No es una guerra entre dos filosofías. Es un problema de enrutamiento.

---

El 73%: Desambiguemos la Cifra Antes de que la Uses Mal

El número aparece en el hilo de dos formas que conviene separar.

Por un lado, el 73% de los SaaS adopta un modelo puro — PLG o Sales-Led. Por otro, el 73% de los SaaS fracasa. Los dos usos se cruzan en un sitio incómodo: el modelo puro es, en sí mismo, el modo de fallo.

No digo que el dato sea una causalidad probada con ensayo controlado. Es correlación. Pero el mecanismo detrás del número tiene más peso que el titular: las empresas se casan con una etiqueta, y la etiqueta sobrevive a la evidencia.

Piénsalo desde la práctica. Cuando hablas con fundadores que han vivido el ciclo completo — del Product-Led start-up al enterprise con ciclo comercial de meses — casi todos te cuentan la misma historia en dos actos. En el acto uno, montan un funnel self-serve impecable, con onboarding que se activa solo, y celebran que nadie necesita tocar a un vendedor. En el acto dos, el ACV sube, aparecen los security reviews, los procurement cycles, los múltiples stakeholders... y de repente la motion self-serve deja de servir para los deals que pagan la nómina.

La mayoría no reacciona cambiando la motion. Reacciona defendiendo la etiqueta. "Somos PLG, vendemos al desarrollo, el enterprise llegará solo." Y el enterprise llega... a la competencia.

❌ El enfoque débil: elegir PLG porque es moda, o porque un inversor lo pide, o porque "todo el mundo lo hace". Basar la identidad en la etiqueta, no en el uso.

✅ El enfoque fuerte: mirar los datos de uso de tu producto hoy. Ver qué motion activa y retiene usuarios de verdad. Y diseñar el sistema para que la motion cambie cuando los datos lo señalen.

La pregunta correcta no es "¿PLG o Sales-Led?". Es "¿qué motion usa cada segmento en cada fase, y qué trigger me dice cuándo cambiar?"

Hay un matiz adicional que conviene capturar: muchos equipos confunden "PLG" con "no hacer sales". Y no es lo mismo. PLG puro significa que el producto es el canal de conversión y expansión, no que no exista un equipo comercial. Incluso en las empresas PLG más canónicas, el sales aparece — solo que enroutado al final del embudo, cuando el usuario ya ha visto valor y el deal justifica un ejecutivo. El error no es tener sales. El error es no tener un trigger que decida cuándo su aparición es productiva y cuándo es ruido.

---

La Lección del 90%: las Peticiones Son Síntomas, en Features Y en Growth Models

Tenemos un aprendizaje previo que se transfiere directo a este problema.

El 90% de los SaaS llena su roadmap con features que un cliente pidió, no con features que los usuarios usan. Las peticiones son síntomas de problemas más profundos, no causas. El resultado son roadmaps llenos de funciones que nadie toca.

El mecanismo es siempre el mismo y conviene desmontarlo con calma. Un cliente importante envía un correo pidiendo una feature. El equipo de Customer Success lo eleva porque "un enterprise lo ha pedido". El product manager lo mete en el roadmap porque tiene presión de revenue. Se construye, se lanza, y un trimestre después nadie lo usa. Pero nadie lo elimina tampoco, porque eliminarlo implicaría admitir que el proceso de priorización funciona mal.

La señal fiable no es la petición. Es el uso. En features y en growth models.

Ahora aplica el mismo sesgo a los modelos de crecimiento. Las empresas no eligen PLG porque los datos de uso lo respalden. Lo eligen porque un stakeholder lo pidió. Porque un board member viene de una empresa PLG y "sabe cómo funciona". Porque un gurú de LinkedIn lo predica. Porque un competidor lanzó un self-serve y "nos estamos quedando atrás".

*Es exactamente el mismo error, un nivel más arriba.*

Y el error se agrava porque la petición no solo influye en la elección inicial: también congela la evolución. Una vez que la empresa se declara PLG, cada petición posterior de intervención comercial (un demo, un call de discovery, un playbook de venta) se rechaza con el mismo argumento: "eso no es PLG". La identidad se convierte en un escudo contra los datos.

Mira tu producto hoy. ¿Quiénes se activan solos? ¿Quiénes necesitan una demo para entender el valor? ¿Qué segmento llega al time-to-value sin tocarte, y cuál se pierde en el onboarding?

Eso es lo único que importa. No lo que pide tu mayor cliente. No lo que hizo un SaaS famoso. Lo que tus datos de uso dicen.

---

El Valor No Está en la Etiqueta: la Lección Transferida del SKILL.md

Hay un segundo aprendizaje que se transfiere perfecto.

En los sistemas de agentes, el valor durable de una skill vive en dos sitios: en la descripción (que funciona como query de un sistema de recuperación) y en los assets empaquetados (que convierten instrucciones en capacidad ejecutable). El fichero de etiqueta — el SKILL.md — es la parte menos importante del sistema.

Esto merece un poco más de desarrollo, porque la analogía es más profunda de lo que parece a primera vista. En un sistema de agentes bien construido, la descripción de una skill no es un titular bonito: es un índice de recuperación. Cuando un agente recibe una tarea, consulta las descripciones para decidir qué skill ejecutar. Si la descripción no refleja con precisión qué puede hacer esa skill, el sistema enrouta mal: elige la skill equivocada, o no encuentra la que tenía capacidad de resolver el problema.

Un modelo de crecimiento funciona igual. La etiqueta "PLG" o "Sales-Led" es tu descripción de recuperación. Si es demasiado vaga o demasiado rígida, el sistema enrouta mal: aplica una motion self-serve a un deal que necesitaba venta asistida, o mete un playbook comercial en un segmento que se activaba perfectamente solo.

Un modelo vale por su mecánica: el loop self-serve, los playbooks de handoff, el packaging de la oferta, el tiempo hasta el valor. No vale por llamarse *"PLG" o "Sales-Led"*.

La etiqueta es, literalmente, la parte menos importante del sistema.

Cuando dices "somos una empresa PLG", estás describiendo la etiqueta, no la mecánica. Cuando dices "enroutamos el self-serve a la larga cola y la venta asistida a los deals complejos", estás describiendo un sistema que funciona.

Uno es identidad congelada. El otro es ingeniería de crecimiento.

Fíjate en el tipo de conversaciones que generan ambas frases. Con la primera, la discusión es filosófica: "¿podemos llamarnos PLG si tenemos un sales team?" Con la segunda, la discusión es operativa: "¿cuál es el trigger exacto que separa un deal complejo de uno self-serve?" Una te lleva a debates de branding interno. La otra te lleva a métricas, playbooks y decisiones ejecutables.

---

El Híbrido No Es Hacer las Dos Cosas en Todas Partes: Es una Decisión de Enrutamiento

Aqui es donde la mayoría se pierde.

El híbrido no significa "hacer PLG y Sales-Led a la vez en todos los segmentos". Eso es confusión operativa con nombre bonito. Es la trampa en la que caen los equipos que, hartos del debate binario, deciden hacer "de todo para todos": producto con self-serve perfecto, sales team persiguiendo cada lead, y ningún criterio que diga quién pertenece a cada vía. El resultado es una organización que hace dos cosas mal en lugar de una bien.

El híbrido es una decisión de enrutamiento, como un sistema de recuperación que sirve el asset correcto según la query. Cada segmento se enruta a la motion que le corresponde:

• Self-serve para la larga cola: usuarios que se activan solos, bajo ACV, time-to-value corto.

• Asistida para los deals complejos: múltiples stakeholders, integraciones profundas, ciclo largo.

• Con un handoff definido entre ambas y un trigger medible que decide cuándo saltar.

Hay una analogía directa con el mundo físico que ayuda a entenderlo. Imagina una carretera con dos carriles: uno de peaje y otro gratuito. El peaje no existe para todo el mundo — existe para los conductores cuyo tiempo vale más que el coste del peaje. La carretera no "es de peaje" ni "es gratuita": es un sistema de enrutamiento que decide en cada entrada qué carril sirve a qué conductor.

Tu producto es esa carretera. El sistema de enrutamiento decide en qué carril entra cada usuario según sus datos de uso, su ACV potencial, su comportamiento de activación. Y puede cambiar de carril en mitad del viaje — ahí está el handoff.

El trigger no es opinión. Es un dato.

---

El Sistema de Enrutamiento por Uso: El Framework de 5 Pasos para Dejar de Ser Puro

Te voy a dejar el marco que uso. Lo llamo el Sistema de Enrutamiento por Uso — un método de cinco pasos para que cada segmento reciba la motion que sus datos de uso justifican.

Paso 1: Audita con uso, no con peticiones

Mide qué motion — self-serve o asistida — activa y retiene usuarios hoy. No lo que piden. No lo que hiciste el año pasado.

Métricas que importan: tasa de activación sin tocar a nadie, time-to-value, porcentaje de usuarios que llegan al aha moment solos, comportamiento de expansión (quién paga más y cuándo).

Un ejercicio práctico que funciona bien: segmenta tu base en cuartiles de ACV y calcula la tasa de activación self-serve de cada cuartil. El resultado suele dibujar una curva reveladora. En la mayoría de los SaaS, el cuartil inferior se activa solo con tasa alta, y el cuartil superior apenas se activa sin intervención. Si tu identidad dice "somos PLG" pero tu cuartil de enterprise no se activa jamás sin un demo, tienes tu respuesta: el problema no es el mercado, es el enrutamiento.

Paso 2: Define el trigger de transición explícito

Señales medibles que indiquen cuándo añadir o cambiar de motion. Sin trigger, el cambio es opinión, no decisión.

Ejemplos: usuarios con determinada tasa de activación se quedan en self-serve. Usuarios con señales de expansión y ciclo largo migran a asistida. Puntos de fricción medibles en el onboarding disparan intervención humana.

La tentación aquí es definir triggers vagos ("cuando el deal sea complejo"). Resistela. Un trigger sirve si un humano puede decir hoy, en este momento, por qué este usuario concreto está en self-serve y aquel no. Si la respuesta depende del criterio subjetivo de cada Account Executive, no tienes un sistema: tienes suerte variable.

Paso 3: Diseña el handoff híbrido

Especifica el punto exacto donde termina el self-serve y empieza la motion asistida. No dejes que sea improvisación del equipo de ventas.

Define playbooks de handoff: qué datos ve la persona asistida, qué contexto del producto recibe, qué se le cuenta al usuario en el cambio. Los assets empaquetados que convierten instrucciones en capacidad ejecutable.

En la práctica, el handoff se rompe casi siempre en el mismo sitio: el contexto. Un usuario ha estado usando el producto de forma self-serve durante semanas, y cuando salta a venta asistida, el comercial le pide que explique qué estaba haciendo. Ese fricción es evitable: el dato ya existe en tu producto. El playbook de handoff debería empaquetar ese contexto y entregárselo al comercial como punto de partida, no como juego de adivinanzas.

Paso 4: Versiona el modelo

Trata el modelo de crecimiento como un artefacto iterable, no como una decisión de una sola vez. Se revisa trimestralmente, se versiona, se a/b testea.

Igual que tu roadmap debería tener features muertas eliminadas, tu growth model debería tener motions retiradas cuando los datos la contradicen.

Este es quizá el cambio cultural más difícil del framework, porque implica aceptar que tu modelo actual tiene fecha de caducidad. Los equipos que dominan esta práctica funcionan con un calendario de revisión fijo: cada trimestre se auditan los triggers, se comparan tasas de activación por segmento, y se versiona el modelo si los datos lo piden. La versión anterior no se descarta — se archiva, como se archiva una feature que fue relevante y dejó de serlo.

Paso 5: Desacopla identidad de mecánica

Elimina el framing "somos una empresa PLG". Sustitúyelo por "usamos motion X cuando los datos dicen Y".

La etiqueta es la parte menos importante. La mecánica que responde al uso es todo el sistema.

---

Las Objeciones Que Te Van a Poner, y la Respuesta

"El foco lo es todo — un híbrido diluye ambas motions."

El foco debe estar en el trigger y el handoff, no en la etiqueta. La rigidez, no la falta de foco, es el mecanismo del fracaso del 73%. Un híbrido bien diseñado no es falta de foco: es un sistema único con dos carriles y una lógica de enrutamiento clara. La dilución ocurre cuando la lógica de enrutamiento no existe y cada motion se improvisa.

"PLG es para productos y Sales-Led para enterprise — es obvio, no se solapan."

El segmento no decide la motion. El uso sí. Hay productos dev-tool con deals enterprise larguísimos, y hay plataformas enterprise con onboarding self-serve impecable. Mide el uso, no el adjetivo del segmento. La etiqueta de segmento es tan poco fiable como la etiqueta de modelo: sigue siendo una identidad congelada aplicada a un mundo que se mueve.

"El 73% es discutible — correlación no es causalidad."

De acuerdo. No uses el titular como veredicto. Usa el mecanismo: decisiones guiadas por peticiones en lugar de uso, y rigidez de identidad que sobrevive a los datos. Eso es lo que mata, y es observable en cualquier SaaS que hayas tocado. No necesitas el titular para validar el mecanismo — basta con mirar tu propio roadmap y ver cuántas features viven en él sin que nadie las toque.

---

La Etiqueta No Te Salva. El Enrutamiento Sí.

El 73% de los SaaS no fracasa por elegir mal entre PLG y Sales-Led. Fracasa por negarse a dejar de serlo.

La falsa dicotomía es el problema. El modelo puro es el modo de fallo. Y la solución no es un tercer modelo con hype: es un sistema de enrutamiento que responde al uso y un trigger que decide cuándo cambiar.

Cuando construyas tu próxima feature, pregunta qué pide el uso, no qué pide el cliente. Cuando elijas tu próxima motion, pregunta qué dicen tus datos de activación, no qué dice tu identidad.

La ventaja competitiva de un SaaS en 2026 no es elegir bien el modelo. Es no enamorarse de él.

Versiona tu modelo como versionas tu código. Un SaaS que se adapta sobrevive. Un SaaS que se casa con su etiqueta, muere con ella. Y la señal para adaptarse no llega desde el board ni desde el gurú de turno: llega desde tu propio producto, desde la telemetría de uso que ya tienes y que decides si escuchar o ignorar.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Tu agent llama a la API. Recibe un HTTP 200. Ejecuta la tool call. Todo parece perfecto.

*Y la tarea ha fallado por completo. *

El agent escribió en el registro equivocado. La acción no tuvo el efecto esperado sobre el estado del sistema. El outcome en el mundo real no coincidió con lo que el output sugería.

Y ningún test unitario, ningún try-catch, ningún framework de testing tradicional va a detectarlo.

Este es el punto ciego estructural del desarrollo de agents en 2026: la mayoría se despliegan sin evaluación estructurada, y sus errores son silenciosos, sistémicos e invisibles. La sabiduría convencional dice que el problema es el modelo — "cambia de modelo, afina el prompt, añade más herramientas". Es exactamente el mismo error categorial que comete el 80% de los SaaS al estructurar sus planes a ciegas: optimizar la cifra en vez de instrumentar el dato.

No necesitas un mejor modelo. Necesitas un harness que clasifique los fallos antes de que puedas medirlos, y que los mida antes de que puedas mejorarlos.

La jerarquía es clasificar → medir → optimizar. Y casi nadie hace los dos primeros pasos.

---

El Punto Ciego Estructural de los Tests Unitarios

Un test unitario verifica que el código devuelve el output correcto. Un agent acierta o falla a nivel de outcome en el mundo real.

Esas dos cosas viven en planos distintos, y ahí reside el problema.

Mira este ejemplo. Tu agent tiene una tool que registra clientes potenciales en un CRM:

```python

test_unitario.py — PASA, pero la tarea real FALLA

def test_registra_cliente():

resultado = agent.run(

herramienta="registrar_prospecto",

input={"nombre": "María", "email": "maria@empresa.com"},

crm="conversoria"

)

El output del código parece correcto

assert resultado.http_status == 200

assert resultado.log == "registro_ok"

✅ El test unitario PASA

```

Ahora mira lo que pasa en producción real:

```python

produccion.py — el outcome NO es el que esperabas

resultado = agent.run(

herramienta="registrar_prospecto",

input={"nombre": "María", "email": "maria@empresa.com"},

crm="conversoria"

)

HTTP 200 ✅ | log = "registro_ok" ✅

PERO el agent escribió en "prospectos_backup"

en vez de la tabla "prospectos_activos"

consulta = "SELECT COUNT(*) FROM prospectos_activos WHERE email='maria@empresa.com'"

❌ 0 filas — la tarea fracasó a nivel de resultado.

```

El test unitario pasó porque verifica el output del código. El agent falló porque el outcome no ocurrió en el mundo.

*Esa brecha entre output y outcome es exactamente el espacio que ningún framework de testing tradicional cubre. *

Y los agents que construyes hoy fallan ahí constantemente. No excepcionalmente — constantemente.

---

Por Qué el Try-Catch es un Error Categorial

Aquí está el giro contraintuitivo que cambia todo lo que sabes sobre errores en agents:

El try-catch modela el fallo como flujo de control excepcional. Pero la clase de fallo dominante en agents no es excepcional.

El sistema completa la ejecución. No lanza nada. No se interrumpe. Y el error vive en el resultado.

```python

❌ Enfoque equivocado: try-catch alrededor de todo

def ejecutar_agent(tarea):

try:

resultado = agent.ejecutar(tarea) # ~2 min de ejecución

return resultado # Nunca lanza — siempre "completa"

except Exception as e:

return manejar_error(e) # ESTE CÓDIGO NUNCA SE EJECUTA

```

El agent nunca lanza una excepción. Devuelve un objeto de resultado "exitoso" que contiene la catástrofe completa sin que nadie se entere.

La recuperación de errores en agents no es un try-catch genérico. Es una máquina de estados por fase — planificar → ejecutar → generar — con un clasificador de errores explícito que decide cómo y cuándo recuperarse:

```python

✅ Enfoque correcto: clasificador + máquina de estados por fase

class FaseAgent:

PLANIFICAR = "planificar"

EJECUTAR = "ejecutar"

GENERAR = "generar"

def clasificar_fallo(contexto) -> Bucket:

"""Clasifica una ejecución en uno de los 4 buckets del harness."""

if contexto["state_ok"] and not contexto["outcome_ok"]:

return Bucket.BUCLE_OCULTO # El agent "completó" pero el resultado no ocurrió

if contexto["tool_seleccionada"] != contexto["tool_requerida"]:

return Bucket.HERRAMIENTA_ERRONEA

if contexto["razonamiento_no_verificado"]:

return Bucket.ALUCINACION_ACCION

return Bucket.CORRECTO

def recuperar(fase_actual, bucket):

if bucket == Bucket.HERRAMIENTA_ERRONEA:

return replanificar(fase_actual) # Replanificar, no reintentar ciegamente

if bucket == Bucket.BUCLE_OCULTO:

return escalar_a_humano(fase_actual) # Escalar — reintentar no servirá

if bucket == Bucket.ALUCINACION_ACCION:

return verificar_estado_y_retry(fase_actual)

return abortar(fase_actual)

```

La decisión de recuperar — reintentar, replanificar, escalar, abortar — pertenece a la taxonomía de evaluación, no al manejador de excepciones.

Esa distinción es la que separa un harness real de un script con try/except.

---

El Framework: El Harness de 4 Buckets para Evaluación de AI Agents

No hay atajo. Este es el proceso completo que convierte tu agent de "creo que funciona" a "medido y justificable".

Paso 1 — Diseña la taxonomía de fallos específica de tu dominio

Los buckets no se copian. Se derivan de los señales observables de tu propio agent.

En un agent de código, el bucket dominante podrías ser selección de herramienta incorrecta. En un agent de soporte, probablemente sea política alucinada. Si copias una taxonomía genérica, obtienes buckets que no clasifican nada de tu realidad.

Define cada bucket en términos de evidencia concreta en tus logs. No en términos abstractos.

| Bucket | Señal observable en tus logs |

|---|---|

| ✅ Correcto | Outcome verificado = esperado |

| 🔧 Herramienta errónea | Tool call ≠ tool requerida para la subtarea |

| 🔁 Bucle oculto | Estado no cambió pese a inputs válidos |

| 🌀 Alucinación de acción | Razón de la acción no verificable en el contexto |

Paso 2 — Construye un suite de tareas doradas

30 a 50 tareas representativas por tipo de tarea. Cada una con un outcome esperado verificable y criterios de aprobación explícitos.

El golden set es el suelo del harness. Sin él, no hay nada que medir.

Paso 3 — Instrumenta el agent

Logs estructurados por fase — plan, tool calls, outputs — que hagan cada ejecución reproducible y clasificable a posteriori.

Sin esto, los buckets no tienen datos que clasificar:

```python

instrumentacion.py — consumo por tarea

def registrar_ejecucion(fase: str, tarea_id: str, tipo_tarea: str, info: dict):

"""Logging estructurado por fase — el proxy no monetario del coste."""

log_estructurado({

"tarea_id": tarea_id,

"tipo_tarea": tipo_tarea,

"fase": fase, # planificar / ejecutar / generar

"tokens_usados": info.get("tokens", 0),

"tool_calls": info.get("tool_calls", 0),

"pasos": info.get("pasos", 0),

"latencia_ms": info.get("latencia_ms", 0),

"modelo": info.get("modelo"),

})

```

Paso 4 — Ejecuta el harness sobre cada candidato

Cada vez que cambias de modelo, de prompt o de versión de herramientas, ejecutas el harness completo. Calculas precisión, fiabilidad y consumo de recursos por tipo de tarea, comparando contra el baseline.

Paso 5 — Convierte el harness en un gate de despliegue

Ejecución en cada cambio. Tracking de métricas en el tiempo. Rollback automático ante regresiones:

```python

gate_despliegue.py — bloquea el deploy ante regresiones

def gate_de_despliegue(resultados_nuevos, baseline):

precision = resultados_nuevos["precision_total"]

fiabilidad = resultados_nuevos["fiabilidad_total"]

if precision < baseline["precision"] * 0.95:

abortar_deploy(f"Precisión degradada: {precision:.1%} vs baseline {baseline['precision']:.1%}")

if fiabilidad < baseline["fiabilidad"] * 0.95:

abortar_deploy(f"Fiabilidad degradada: {fiabilidad:.1%} vs baseline {baseline['fiabilidad']:.1%}")

if resultados_nuevos["tokens_por_tarea"] > baseline["tokens_por_tarea"] * 1.3:

abortar_deploy("Consumo de recursos disparado — revisa la nueva versión")

activar_deploy()

```

Esto es lo que convierte "creo que funciona" en una afirmación medida.

---

"¿La evaluación con LLM no es subjetiva?"

Te escucho. "¿Quién decide que una ejecución falló?"

La respuesta es un enfoque híbrido que no depende de un juez único:

1. Comprobaciones deterministas de outcome: aserciones sobre el estado final, verificación de tool calls.

2. LLM-as-judge calibrado contra etiquetas humanas en un subset del golden set.

Los 4 buckets son una capa de clasificación, no un juez único. Las reglas deterministas cazan el 80% de los fallos silenciosos (el ejemplo del registro equivocado). El LLM-as-judge cubre el resto, y se calibra contra personas reales — no contra otro LLM.

---

"¿No es overkill para un prototipo?"

El harness arranca con un smoke suite de 10 tareas y los 4 buckets. El coste es incremental.

Se amortiza en la primera regresión silenciosa que detecta antes de llegar a producción. Y para un agent de prototipo, la pregunta relevante no es "¿puede hacer esto?" sino "¿puedo justificar que haga esto en producción?"

Un agent sin harness no puede justificarse. No puede mejorarse con evidencia. No puede defenderse contra regresiones.

---

La Lección que se Transfiere Completa

El paralelismo con el pricing es el argumento profundo de todo esto. El 80% de los SaaS estructura sus planes a ciegas — optimizan la cifra en vez de instrumentar el uso. Los equipos de agents optimizan el prompt en vez de instrumentar los outcomes.

Ambos fracasos son epistemológicos, no numéricos. Ambos comparten la misma jerarquía rota: optimizar antes de medir, medir antes de clasificar.

Primero se mide. Luego se optimiza. Siempre en ese orden.

Lo que te llevas

• Los tests unitarios detectan crashes y violaciones de contrato, no fallos silenciosos de outcome — son complementarios al harness, no sustitutos.

• El try-catch es un error categorial: el fallo dominante en agents no es excepcional, vive en el resultado.

• Los 4 buckets convierten los logs ruidosos en una señal agregable por tipo de tarea, comparable entre candidatos y trackeable en el tiempo.

• Medir consumo por tarea (tokens, tool calls, latencia) añade la tercera dimensión: no basta con que sea correcto, tiene que ser eficiente y fiable en cada tipo de tarea.

• El harness es el único mecanismo que hace seguros los rollbacks y las actualizaciones de modelo.

El futuro de los agents no lo deciden los modelos más grandes ni los prompts más largos. Lo deciden los equipos que instrumentan sus outcomes, miden por tipo de tarea y convierten cada regresión silenciosa en una señal accionable.

El harness no es un gasto de ingeniería. Es la diferencia entre un agent que demuestra valor y un agent que finge tenerlo.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Crees que tu problema es que no sabes qué construir a continuación. Que si tuvieras más feedback, más llamadas con clientes, más votos en el backlog, tendrías claridad.

*Te has equivocado de diagnóstico.*

El 90% de los SaaS construye features porque un cliente lo pidió — no porque los usuarios las usen. Y ese es exactamente el motivo por el que tu roadmap es un cementerio de funciones que nadie abre.

Construyes porque alguien gritó. No porque la telemetría lo confirme.

La sabiduría convencional dice "escucha a tus clientes" y "construye lo que piden". El mercado asume que el volumen de peticiones es una señal de demanda.

*Es falso. Y es caro.*

Vamos a desmontarlo, vamos a darte el framework, y vas a dejar de construir funciones fantasma.

---

El Sesgo de la Minoría Ruidosa: Tu "Roadmap Democrático" es una Dictadura de los que Más Gritan

Mira tu inbox. Los clientes que te escriben emails, abren tickets y exigen features no son una muestra representativa.

Son los más vocalizados. Los más grandes. Los más frustrados.

Los que se dan de baja en silencio jamás votan en tu backlog. Simplemente se van. Así que tu feedback es una muestra sesgada por diseño: solo escuchas a los que aún están enfadados contigo, no a los que ya se fueron sin decir nada.

El "roadmap democrático" que venden los frameworks de community voting no es democracia. Es captura por parte de los que más gritan.

Y hay una conexión directa con el eje de retención: la petición ruidosa casi nunca viene de la cohorte que está en riesgo de churn. Viene de la cohorte que ya está comprometida. Construyes para contentar a los que se quedan, mientras los que están a punto de irse no te dicen ni una palabra.

Piénsalo desde la mecánica del incentivo. Un cliente que lleva dos años contigo, que ya ha invertido tiempo en configurar el producto y que forma parte de tu plan enterprise, tiene todo el motivo del mundo para escribirte cuando algo le falta. Está comprometido, quiere que el producto mejore porque su éxito depende del tuyo. Pero el usuario que probó tu producto la semana pasada, tropezó con la misma carencia y simplemente cerró la pestaña… ese no te escribe jamás. Ni te envía un ticket de soporte. Ni te da un voto en tu portal de feedback. Solo desaparece.

El resultado es un bucle de retroalimentación corrompido. Cada feature que construyes para el cliente vocalizado no solo te cuesta tiempo y recursos: te aleja aún más de los usuarios que no hablan. Y mientras más te alejas, más dependes de las mismas voces ruidosas para saber qué construir. El problema se retroalimenta.

❌ El enfoque débil: "Este cliente grande pide export a CSV. Lo ponemos en el roadmap."

✅ El enfoque fuerte: "¿Qué cohorte está abandonando en silencio? ¿Qué contratan y no usan? Respondamos eso antes de tocar el backlog."

La diferencia entre ambos enfoques no es sutil. Es la diferencia entre un equipo de producto que reacciona y uno que dirige. El primero acumula deuda para la mayoría silenciosa a cambio de contentar al 5% que grita. El segundo invierte esa ecuación: la señal de retención — qué cohortes se quedan, qué cohortes se van, qué patrón de uso precede a la baja — es la brújula que guía el roadmap. Y esa señal no llega por email. Llega por telemetría.

---

Síntomas vs. Soluciones: El Cliente no Pide el Botón. Pide el Resultado.

Un cliente que pide "exportar a CSV" no quiere un botón.

Quiere resolver un problema de reporting que probablemente ya intenta resolver con copiar-pegar, con una herramienta externa o con una hoja de cálculo manual.

Si construyes el botón literal, resuelves el síntoma. Listo, una feature más que nadie usará como esperabas.

Si investigas el job-to-be-done —"¿qué resultado intentas conseguir?"— descubres que la solución real puede ser un dashboard mejor, una integración con su herramienta favorita, o un reporte programado con más impacto y menos coste de mantenimiento que el botón literal.

Cada petición es un síntoma de un problema más profundo. Rastrearlo antes de aceptarla como orden de trabajo separa a los equipos que construyen producto de los que construyen botones.

Existe un patrón clásico que se repite en todos los SaaS: el cliente pide la solución literal que ya se le ha ocurrido, no la solución óptima. Es humano. Es el sesgo de disponibilidad aplicado a la ingeniería de producto. Cuando alguien está harto de copiar y pegar datos de tu interfaz a una hoja de cálculo, su primera idea es "exportar a Excel". No piensa en "reporte programado" ni en "dashboard interactivo". No tiene por qué: su trabajo es gestionar sus números, no diseñar tu producto.

Tu trabajo, sin embargo, sí es entender el resultado final. Y la buena noticia es que la práctica de entrevistar el job-to-be-done tiene una técnica concreta: preguntar siempre la pregunta de rastreo. Cuando alguien te pide una feature, responde con "¿y qué estás intentando conseguir con eso exactamente?" — y cuando te responda, pregunta otra vez "¿y eso para qué?" — y así hasta llegar a la capa de resultado. Casi siempre necesitas rascar tres o cuatro capas para descubrir el problema subyacente real. La petición original, "necesito un botón de export", es lo último que deberías tomar literalmente.

Y este patrón no es un accidente aislado. Es sistémico. El 80% de los SaaS estructura sus planes de precios a ciegas, sin mirar ni un dato. El mismo síndrome de "decidir sin evidencia" que produce planes al azar produce roadmaps por petición. Son dos caras de la misma enfermedad cultural: equipos que reaccionan a voces en lugar de leer telemetría.

---

El Coste Oculto de las Features Fantasma

Cada feature construida para un solo cliente ruidoso tiene un coste que casi nadie calcula.

No es el sprint. Es el legado.

Una feature que nadie usa añade deuda permanente de mantenimiento. Superficie de bugs. Complejidad de onboarding. Cada botón nuevo que no aporta valor confunde al usuario que llega por primera vez. La feature fantasma es un impuesto que todos los usuarios futuros pagan en forma de producto más confuso.

El coste real no es el tiempo de desarrollo. Es el producto que pudo haber sido.

Cada feature construida para complacer a una voz es una feature que NO se construye para la mayoría silenciosa que ya usa el producto. El coste de oportunidad de decir "sí" a un grito es decir "no" a cientos de usuarios que simplemente no te escribieron.

Vamos a ponerle números concretos a esa deuda, porque el coste se siente abstracto hasta que lo descompones. Cada feature de baja adopción implica:

• Mantenimiento perpetuo: Bugs que se descubren y se arreglan aunque nadie use la feature. Cada release que toca código colindante riesgo de romperla.

• Tests y suites: Cada feature nueva necesita su cobertura de tests. Tests que ejecutan CI que debería ejecutar features que el usuario usa.

• Densidad cognitiva: Cada opción visible en la interfaz compite por la atención del usuario. Un cliente nuevo que ve siete botones que no entiende abandona el onboarding más rápido que uno que ve tres botones claros.

• Documentación y soporte: Artículos de ayuda, preguntas de Soporte sobre "¿cómo funciona esto?" de features que nadie usa. Recursos que se destinan a explicar algo que debería haber sido un dashboard interno.

• Coste de reversión: Cuando finalmente reconoces que la feature es un lastre y decides retirarla, tienes que gestionar la migración, el versionado, y la queja inevitable del cliente que la pidió (y que quizá tampoco la usaba, pero se siente propietario).

Todo eso es un impuesto silencioso que pagas todos los días. Y el problema es que se acumula con el tiempo: diez features fantasma construidas en dos años pueden añadir más deuda de mantenimiento que todas las features reales juntas.

---

El Marco de los Tres Ejes: Impacto × Retención × Valor Estratégico

Este es el framework que uso para decidir qué construir en mis propios productos. Lo llamo El Marco de los Tres Ejes. Y la primera regla es no negociable.

Regla 1: Instrumenta antes de pedir.

Mide uso por feature y por segmento antes de aceptar cualquier petición como hecho. Frecuencia de uso, adopción, activación, abandono. Necesitas saber qué se usa, qué se ignora y qué se abandona antes de que alguien te pida nada.

Cada request se registra como una hipótesis contrastable contra la telemetría existente. No como una orden de trabajo.

La instrumentación no tiene que ser exhaustiva. Empieza por lo mínimo: ¿qué features están activas en la sesión típica de cada segmento? ¿Cuál es el rate de activación del onboarding? ¿Qué flujos terminan en abandono? Con esas tres métricas cubiertas, ya tienes suficiente señal para contrastar la mayoría de peticiones. El 80% de las peticiones de features nuevas se pueden evaluar contra "¿hay evidencia en la telemetría de que una carencia en este flujo está provocando abandono?"

Regla 2: Clasifica cada petición por su job-to-be-done.

No preguntes "¿qué botón quieres?". Pregunta "¿qué resultado intentas conseguir?". Documenta el problema subyacente y agrupa peticiones distintas que comparten el mismo síntoma raíz.

```markdown

Registro de peticiones

Petición: "Necesito exportar datos a Excel"

Job-to-be-done: "Quiero hacer informes mensuales sin copiar-pegar"

Síntoma raíz: Reporting nativo inexistente

Solución real probable: Dashboard + reporte programado

Score hipótesis pendiente de telemetría: Confirma rate de workaround primero

```

Este registro cumple una función importante que la mayoría de backlogs no tienen: agrupar. Ocho peticiones distintas — "export a Excel", "necesito filtros avanzados", "quiero programar envios", "me gustaría un calendario de reportes" — pueden compartir el mismo síntoma raíz de "reporting nativo pobre". Si las tratas como ocho features separadas, construyes ocho soluciones parciales. Si las agrupas por síntoma raíz, construyes una solución que las resuelve todas a la vez. El registro de peticiones es la herramienta que permite esa agrupación.

Regla 3: Puntúa cada feature en tres ejes, escala 1-5.

• Impacto en cliente: ¿A cuántos usuarios o segmentos beneficia? No "¿quién lo pidió?", sino "¿quiénes lo usarían?"

• Riesgo de retención: ¿Qué cohorte está en riesgo si NO lo construimos? Este eje prioriza a los que se van en silencio, no a los que gritan.

• Valor estratégico: ¿Nos acerca a la visión de producto o nos desvía?

Suma las tres puntuaciones. Ordena el backlog. Borra del liderazgo cualquier feature que la telemetría no respalde.

Regla 4: Umbral de corte y re-priorización trimestral.

Las peticiones antiguas no ganan prioridad por antigüedad. Ganan por su puntuación actualizada con datos frescos de uso. Re-evalúa el backlog entero cada trimestre y descarta lo que ya no pasa el umbral.

Este es el punto más difícil de interiorizar culturalmente, porque choca con la intuición de "si llevan pidiéndolo dos años, será importante". La antigüedad no es una señal de demanda. Es una señal de ruido persistente. Una petición que lleva dos años en el backlog sin que nadie la recuerde suele ser una petición que nadie necesita de verdad — o la necesita muy poca gente, y muy ruidosa. Si fuera realmente crítica, la telemetría lo demostraría en forma de abandono creciente. Si no lo demuestra, lo único que la mantiene viva es la inercia. El trimestre es tu ciclo natural de recolección de datos: con tres meses de telemetría fresca puedes comparar cómo han evolucionado los patrones de uso antes de commitear recursos.

Regla 5: Valida con el slice más pequeño.

Lanza la feature en versión mínima a un segmento. Define de antemano la métrica objetivo — retención o activación. Mide el cambio real antes de comprometer recursos completos.

```javascript

// Ejemplo de feature gate para validación de una feature nueva

const shouldShowFeature = (user, feature) => {

// solo el 5% de la cohorte de prueba ve la feature

const inTestSegment = hash(user.id + feature.name) % 20 === 0;

const metricName = feature.successMetric || "activation";

return inTestSegment ? track(metricName) : null;

};

```

El patrón de feature gating que ves en el código es exactamente lo que separa a los equipos que aprenden de los que suponen. El slice más pequeño no es un atajo cutre: es la unidad de aprendizaje más eficiente que existe en producto. Si la feature tiene el impacto esperado en el 5% de la cohorte, tienes evidencia para escalar. Si no lo tiene, has invertido el 5% del coste que habría supuesto construirla entera para descubrir que nadie la usa. El fracaso barato es una herramienta de producto tan valiosa como el éxito.

Y aquí la analogía con la ingeniería de software a gran escala es esclarecedora. Cuando un proyecto enorme se atasca, no suele ser porque alguien no sepa escribir código. Se atasca en la planificación, el diseño y la coordinación que rodean al código: entender el sistema existente, decidir qué construir y en qué orden, mantener la alineación con el objetivo original. El mismo principio aplica a tu roadmap de features: el problema rara vez es "no sabemos qué construir". El problema es que el proceso de decidir está capturado por voces ruidosas en lugar de evidencia de uso.

---

Respondiendo a Tus Objeciones

"Los clientes enterprise exigen features concretas para cerrar el deal."

Distingue entre compromisos contractuales y roadmap discrecional. Lo primero se negocia y se instrumenta igualmente. Lo segundo pasa por el mismo filtro de los tres ejes. Un deal que depende de una feature unica de un solo cliente es un deal que probablemente se cae igualmente en el primer renew.

Esta objeción es la más común y la más legítima. Nadie dice que ignores a los enterprise. Lo que dice el framework es que distingas entre lo que se negocia en el contrato y lo que entra en el roadmap. Si un cliente enterprise quiere una integración con su ERP, eso se negocia, se presupuesta, se instrumenta — y se entrega con métricas de adopción definidas. Eso es un proyecto. Pero cuando el mismo cliente enterprise te pide, fuera de contrato, una feature "que su equipo lleva pidiendo meses", esa petición entra en el mismo embudo de los tres ejes que cualquier otra. El tamaño del cliente infla el volumen de la voz, pero no la evidencia de uso. Y cuidado con el patrón perverso: el cliente que te chantajea con el renewal para conseguir features suele ser el mismo que se da de baja igualmente porque su problema real era otro. Construyes el plugin de SAP que pidió, no lo usa nadie de su equipo, y el renewal se cae igualmente porque el problema era la falta de soporte, no la falta del plugin.

"Los datos de uso solo te dicen lo que existe, no lo que falta."

Existen señales proxy medibles. Workarounds detectados en sesiones. Tickets de soporte recurrentes. Búsquedas fallidas. Rate de abandono en flujos clave. Y los experimentos de feature gating miden demanda real con audiencia pequeña antes de comprometer el roadmap.

Los datos de uso no te dicen directamente qué falta, es cierto. Pero te dicen dónde buscar. Un usuario que copia manualmente datos de tu interfaz para pegarlos en otra herramienta es una señal proxy. Un usuario que escribe "export" en la búsqueda de tu documentación y no encuentra nada es una señal proxy. Un flujo de onboarding con un 70% de abandono en el tercer paso es una señal proxy. Todas son medibles con las herramientas que ya tienes. El problema no es que los datos no digan qué falta — es que los equipos no los leen con la intención de averiguarlo. La telemetría convierte la "falta" en una hipótesis contrastable, y eso es una ventaja enorme sobre la petición literal.

"No tengo data team ni infraestructura de analytics."

El framework no exige un data warehouse sofisticado. Evidencia cualitativa estructurada a escala — clasificar tickets, entrevistas de job-to-be-done, sesiones grabadas — supera a una sola voz ruidosa. Y la instrumentación mínima se hace con herramientas de producto estándar.

Este es el mito más extendido y el más fácil de desmontar. No necesitas un equipo de data engineering para aplicar el Marco de los Tres Ejes. Necesitas:

• Una hoja de cálculo donde clasifiques tickets por síntoma raíz — puedes hacerlo en una tarde y ya tendrás más señal que la mayoría de los SaaS.

• Tres preguntas estructuradas en tus entrevistas de cliente: "¿qué intentabas conseguir?", "¿cómo lo resuelves hoy?", "¿qué te ha frenado?". Con esas tres preguntas en veinte entrevistas has matado la ambigüedad de mil peticiones.

• Herramientas de producto estándar para el gating: la mayoría de plataformas de analytics de producto — PostHog, Amplitude, Mixpanel — incluyen feature flags y tracking de eventos con una configuración mínima. La instrumentación mínima no es un proyecto: es una tarde de trabajo.

El verdadero coste no es la infraestructura. Es la disciplina de preguntarse "¿qué evidencia tengo?" antes de preguntarse "¿qué me han pedido?".

---

Del Backlog Congelado al Bucle de Aprendizaje

Priorizar bien no termina en la decisión. Termina en la validación.

La disciplina de lanzar el slice más pequeño con una métrica objetivo definida convierte la priorización en un bucle: cada feature lanzada y medida actualiza el score de las siguientes. El backlog mejora con cada iteración en lugar de congelarse en la opinión del día uno.

Fíjate en cómo funciona el bucle. Lanzas el slice pequeño de la feature A. Mides retención. Los datos dicen que la adopción es baja pero la activación sube en el segmento de prueba. Ese resultado actualiza el score de la feature B (que compartía síntoma raíz con A) y te dice si vale la pena mejorarla. Mientras tanto, la petición del cliente C que llegó la semana pasada se evalúa contra la telemetría recién generada — y quizá se agrupa con A y B en lugar de abrir un frente nuevo. El backlog deja de ser una lista estática de deseos y se convierte en un conjunto de hipótesis vivas que evolucionan con cada dato nuevo.

Los equipos que sobreviven en SaaS no son los que escuchan mejor. Son los que miden primero y preguntan después. La próxima vez que un cliente grite una feature, no abras el código.

Abre la telemetría.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

No es documentación. Es la query string de un sistema de recuperación que decide si tu skill se usa alguna vez.

Claude no carga tu skill porque esté en la carpeta. La carga solo cuando la descripción coincide con la tarea del usuario. Escribes una descripción vaga, y tu skill es un zombi: existe, pesa cero en el contexto, pero jamás se dispara.

Y los equipos que copian sus system prompts en un SKILL.md van a ver cero beneficio y van a concluir que la feature no funciona.

Casi nadie lo analiza así, así que vamos a destriparlo: *el fichero SKILL.md es la parte menos importante de la skill*. El valor real vive en tres capas que nadie menciona.

---

No es un Prompt de Sistema con Carpeta. Es un Sistema de Recuperación

El argumento que oyes en cada oficina: "¿Para qué complicarme? Lo hago con un prompt de sistema personalizado."

Ahí está el error conceptual.

Un prompt de sistema está siempre en contexto. Cada instrucción que añades paga token en cada llamada, compite con la tarea real del modelo y degrada la calidad cuando acumulas contenido. Con 50 system prompts encima, tienes un agente lento, caro y confuso.

La skill invierte ese tradeoff.

Puedes tener 50 skills para 50 dominios y pagar coste base cero, porque solo entra en contexto la que coincide. Eso convierte a las skills en una primitiva de escalado, no en un detalle de formateo.

Es la diferencia entre un bundle de prompts de 200KB y un agente limpio que tira de conocimiento experto exactamente cuando lo necesita.

Mirad el formato real. Una skill es una carpeta con un SKILL.md que tiene frontmatter YAML y un cuerpo en Markdown:

```markdown

---

name: normalizador-csv

description: >

Usa cuando el usuario pida fusionar, limpiar, convertir o reformatear

datos CSV, hojas de cálculo o ficheros exportados desde Excel o Google

Sheets. También si pega una tabla con columnas inconsistentes o fechas

en formatos mixtos.

---

Normalizador CSV

Normaliza ficheros CSV a un esquema consistente:

• Columna `id` siempre primera.

• Fechas en ISO 8601 (YYYY-MM-DD).

• Eliminar filas duplicadas.

• Solo conservar las columnas definidas en `schemas/template.json`.

```

Fijaos en la descripción. No es un resumen de producto. Es un índice de intenciones de usuario. Dice en qué situaciones dispararse, qué frases la activan y qué tipo de inputs acepta.

Eso no lo escribe casi nadie. Y es la diferencia entre una skill que funciona y una skill invisible.

---

Las Skills-Versus-MCP: Donde la Arquitectura de Casi Todos se Va al Carajo

Desde el anuncio, la reacción en dos bandos:

❌ "Es un prompt de sistema con pasos extra"

❌ "Necesito montar un servidor MCP para cada capacidad"

Ambas están mal.

Los servidores MCP son para integraciones con estado, externas, del lado del servidor: bases de datos vivas, APIs de terceros, herramientas que mantienen sesiones.

Las skills son para capacidad *stateless* y autocontenida: transformación de ficheros, formateo específico de dominio, heurísticas empaquetadas.

Los ejemplos oficiales de Anthropic — decodificar un QR y convertir PDF a Markdown — son problemas de script-en-una-carpeta. Y aun así, los equipos montan un servidor MCP completo para cada uno, pagando infraestructura y mantenimiento por algo que resuelve una carpeta versionada.

El test es brutalmente simple: ¿la capacidad necesita estado compartido o un server-side runtime? Si la respuesta es no, es una skill.

Aquí está el patrón de paquete de capacidad: texto que instruye + asset que ejecuta.

```markdown

---

name: extraer-metadatos-imagen

description: >

Usa cuando el usuario pida extraer metadatos de imágenes (EXIF, GPS,

fecha de captura, cámara) o ordenar una carpeta de fotos por estos datos.

---

Extracción de Metadatos

Ejecuta el script incluido con el fichero a analizar:

```

python scripts/extract_exif.py <ruta-al-fichero>

```

Muestra solo: fecha, cámara, coordenadas GPS si existen.

Si no existe el script, pídele al usuario que lo reinstale.

```

Y en la carpeta, junto al SKILL.md:

```python

scripts/extract_exif.py

import sys

from PIL import Image

from PIL.ExifTags import TAGS, GPSTAGS

def main(path):

img = Image.open(path)

exif = img._getexif() or {}

data = {}

for tag_id, value in exif.items():

tag = TAGS.get(tag_id, tag_id)

if tag == "GPSInfo":

data["gps"] = {GPSTAGS.get(k, k): v for k, v in value.items()}

else:

data[tag] = value

print({k: v for k, v in data.items()

if k in ("DateTime", "Model", "Make", "gps")})

if __name__ == "__main__":

main(sys.argv[1])

```

Una skill que solo contiene prosa es una skill a medias. El asset empaquetado es lo que la convierte en capacidad, no en sugerencia.

---

El Patrón de las 3 Capas del Paquete de Capacidad

Tras construir varias en producción, este es el marco que funciona. No es teoría: es el orden en que escribo cada skill nueva.

1. Encuentra las 3–5 tareas que tu equipo repite y que el modelo base hace mal

No busques demos impresionantes. Busca el trabajo real repetido a diario: "formatear nuestros partes de incidencias" o "convertir los PDF de proveedores a markdown". Esas, no las demostraciones, son los candidatos reales.

2. Crea la estructura de carpeta y escribe la descripción AL FINAL

Crea `.claude/skills/<nombre-de-skill>/SKILL.md`. Escribe primero el cuerpo. Luego la descripción, como una búsqueda: enumera frases disparadoras, intenciones de usuario y tipos de input para que la capa de recuperación pueda hacer match.

Si la skill nunca se dispara, el bug es la descripción. Si se dispara pero hace algo incorrecto, el bug es el cuerpo. Apunta a ambos por separado.

3. Mueve TODO lo ejecutable fuera de la prosa y dentro de assets

Cualquier script, lista de regex, plantilla o ejemplo few-shot va como fichero en la carpeta, referenciado desde el cuerpo. Mantén el cuerpo lo suficientemente corto para que cargue barato.

Mirad la diferencia entre la v1 y la v2 de la misma skill:

❌ v1: un ensayo de 400 palabras de instrucciones sobre cómo normalizar datos, con ejemplos inline, edge cases enterrados en prosa y reglas que el modelo debe recordar.

✅ v2: 60 palabras de cuerpo + un script ejecutable + una plantilla JSON referenciada. El contexto que entra es mínimo. La lógica vive en código testable, no en memoria del modelo.

4. Testea con tareas reales del paso 1, e itera sobre la descripción (no solo las instrucciones)

Si la skill no se dispara, reescribe la descripción como índice de intención de usuario. Trátala como SEO y haz A/B tests. Una skill que nunca se dispara es invisible por muy bueno que sea su cuerpo.

5. Empaqueta y distribuye como código

Haz commit en un repo de git, añade un manifiesto de plugin y trata el SKILL.md como código fuente: code review los cambios, versiona, haz rollback.

Así se ve el empaquetado para distribución:

```json

{

"name": "normalizador-csv",

"version": "1.2.0",

"description": "Normaliza CSV y hojas de cálculo a un esquema consistente.",

"skills": ["./skills/normalizador-csv"]

}

```

Esa capa de distribución es la feature dormida del ecosistema. Convierte la capacidad de un agente en un artefacto de software con versionado, revisión y rollback. Es la misma progresión que vivió el mundo de los package managers con las librerías.

---

Los Assets, no el Prompt, son el Producto

Cuando Anthropic lanzó Agent Skills en octubre de 2025, los ejemplos oficiales no eran prosa elegante. Eran un decodificador QR (script basado en OpenCV) y un conversor de PDF a Markdown (script con Amazon Textract).

*Un skill es un mini-paquete de capacidad: instrucciones + assets ejecutables. * No una plantilla.

La consecuencia práctica: el acto de escribir un SKILL.md fuerza a tu equipo a externalizar conocimiento tribal que vive en cabezas de seniors y hilos de Slack. "Aquí está exactamente cómo normalizamos los datos de cliente." Ese valor documentado compone antes de que la automatización sea perfecta.

Y es revisable, diffable y responsable de una forma que un prompt de sistema de pared de texto jamás será.

---

Cómo Responder a las Objeciones

"Es un prompt de sistema en una carpeta."

Un prompt de sistema está siempre en contexto y paga token en cada llamada. No puede empaquetar assets ejecutables. No se versiona ni se distribuye limpio. La carga bajo demanda, el empaquetado de assets y el distributable son el producto real.

"Las skills son poco fiables, no disparan la mía."

Eso es casi siempre un fallo de recuperación por la descripción, no del modelo. La solución es reescribir la descripción como un índice de intención de usuario y testearla. La fiabilidad es disciplina de diseño, no un regalo.

"Esto me ata a Claude y Claude Code."

El formato SKILL.md es Markdown plano + YAML, y los assets son ficheros ordinarios. El artefacto es portable; el conocimiento sobrevive aunque cambie el runtime. Lo que se ata es el comportamiento de recuperación, no el contenido. Sé honesto: el marketplace y el ecosistema son específicos de Claude, pero el formato no es profundamente propietario.

---

El Futuro del "Prompt Engineering" es Mantenimiento de Software

Los equipos que adopten este workflow pronto están construyendo activos organizacionales reutilizables, no automatizaciones de usar y tirar.

La diferencia entre escalar con 50 skills bien descritas y versionadas, o ahogarse con un system prompt monolítico de 200KB, es la misma que separa a un equipo que mantiene librerías de uno que copia código en Slack. Construye el activo. La descripción conviértela en query string, los assets en código, y la distribución en tu estándar de calidad.

Porque el que trata las skills como prompts de sistema ya está pagando el impuesto. Solo que todavía no lo nota.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

No es culpa del modelo. Es culpa de tu try-catch.

La mayoría de los desarrolladores tratan los AI agents como software determinista. Escribís código que asume que el LLM devolverá JSON válido. Que la tool call funcionará. Que el contexto cabrá en la ventana.

Y cuando falla, ponéis un try-catch alrededor del loop y llamáis a eso "error handling".

*El problema no es que los agents fallen. Es que los tratáis como funciones puras cuando son sistemas estocásticos. *

Y un sistema estocástico no lanza excepciones. Produce respuestas plausibles pero incorrectas. Tool calls alucinadas con argumentos perfectamente formados. JSON válido que describe la cosa equivocada.

El try-catch es la herramienta equivocada no porque esté mal implementado. Es porque captura exactamente la categoría de error que no es el problema real.

---

El Problema: El Fallo de un LLM Casi Nunca Llega como Excepción

En software determinista, una excepción tiene semántica definida. Un `TimeoutError` significa que algo tardó demasiado. Un `SchemaError` significa que los datos no encajan. El handler sabe exactamente qué pasó y qué hacer.

Con un LLM, el "error" rara vez llega como excepción. Llega como:

• Una respuesta sintácticamente correcta pero semánticamente errónea.

• Un argumento de tool alucinado que parece plausible.

• Un JSON malformado que solo descubre el parser, cuando ya es tarde.

El momento en que se dispara tu `except` es el momento en que el sistema estocástico ya te mintió.

Y ojo: el retry con backoff que te ha funcionado toda la vida también falla aquí. Los retries solo cubren errores transitorios — un 429 de rate limit, un timeout temporal. Si el fallo es silencioso (respuesta incorrecta pero válida), el retry re-ejecuta el mismo fallo y le llama "recuperación".

> ❌ El error del enfoque clásico:

> - try-catch alrededor del loop → no captura fallos silenciosos

> - retry + backoff genérico → repite el mismo fallo en bucle

> - "más contexto" → no arregla una tool caída

> - "un modelo mejor" → sigue siendo estocástico

> ✅ El enfoque que funciona:

> - Classificar el error antes de decidir la recuperación

> - Handlers específicos por fase (planificar, ejecutar, responder)

> - Fallar hacia la seguridad: auto-recuperar solo con confianza alta

> - Instrumentar cada recuperación para aprender de ella

La recuperación de verdad no es un bloque de excepciones. Es una máquina de estados con handlers específicos por fase.

---

La Evidencia: Por Qué los Retries "Funcionan" sin Funcionar

Hay una razón por la que tantos agentes pasan las demos y se rompen en producción. La demo es un camino de felicidad: el modelo devuelve lo esperado, la tool responde, el JSON parsea. En producción el espacio de fallos se multiplica — rate limits de una API de terceros, tools caídas a las 3 de la madrugada, esquemas que cambian sin avisar, inputs adversariales.

A quienes les funciona el retry con backoff, les digo una cosa: funciona porque el fallo es transitorio, no porque tu código de recuperación sea bueno. Estás cubriendo el 20% de los fallos y llamándolo solución.

Un clasificador de errores bien construido no sustituye al retry. Le dice al retry cuándo tiene sentido y cuándo está tirando el dinero.

Taxonomía de errores

El primer paso es inventariar los fallos reales de tu agente. Recorre tus logs de producción y clasifica cada incidente en una de estas categorías:

```python

error_taxonomy.py

from enum import Enum

class ErrorCategory(Enum):

TRANSIENT = "transient" # rate limit, timeout, API caída

PERMANENT = "permanent" # schema changed, auth revoked

AMBIGUOUS = "ambiguous" # no sabemos qué pasó

TOOL_FAILURE = "tool_failure" # la tool existe pero falla al ejecutar

MODEL_OUTPUT_INVALID = "output_invalid" # JSON malformado, arg alucinado

Mapping explícito de excepciones conocidas y status codes

ERROR_MAP = {

429: ErrorCategory.TRANSIENT,

503: ErrorCategory.TRANSIENT,

401: ErrorCategory.PERMANENT,

400: ErrorCategory.AMBIGUOUS, # puede ser un arg malformado del modelo

}

```

La clave: el clasificador opera también sobre outputs sintácticamente exitosos, no solo sobre excepciones.

Un JSON que parsea pero devuelve un argumento imposible (una cita fuera de horario en un sistema de reservas) entra en `MODEL_OUTPUT_INVALID`. Ahí no hay excepción. Ahí hay semantic validation: un validador de resultados, no un parser.

---

La Máquina de 3 Fases: Plan → Tool → Respond

Recuperarse de una fallo no es un acto. Es un proceso que depende de en qué fase del ciclo esté tu agente cuando falla.

Retryar una llamada a tool fallida es barato. Pero retryar un plan fallido re-ejecuta trabajo ya hecho y multiplica coste y latencia. Y re-ejecutar sin más cuando falla la generación de respuesta es repetir exactamente el mismo fallo.

Cada fase necesita su propio mecanismo de recuperación:

Fase 1: Planificación → re-plan con feedback

Si el plan propuesto lleva a un callejón sin salida, no repitas el plan. Re-planifica inyectando el error como feedback en el contexto del modelo.

```python

def replan_with_feedback(agent, plan, error_feedback):

"""Re-planifica inyectando el error para que el nuevo plan lo evite."""

prompt = agent.build_plan_prompt(

previous_plan=plan,

feedback=f"El plan anterior falló en el paso 3: {error_feedback}. "

f"Elimina ese paso o sustitúyelo por una alternativa."

)

return agent.generate_plan(prompt)

```

Fase 2: Ejecución → retry + circuit breaker

Para errores transitorios en una tool: retry con exponential backoff + jitter. Para fallos repetidos: circuit breaker — corta la tool tras N fallos consecutivos y reanuda desde el último paso persistido en vez de reiniciar el workflow completo.

```python

circuit_breaker.py

class CircuitBreaker:

def __init__(self, failure_threshold=3, cooldown_seconds=60):

self.failure_threshold = failure_threshold

self.cooldown = cooldown_seconds

self.failures = 0

self.open_since = None

def allow_request(self) -> bool:

if self.open_since and (time.time() - self.open_since) > self.cooldown:

self.reset() # half-open: probamos de nuevo

return True

return self.failures < self.failure_threshold

def record_failure(self):

self.failures += 1

if self.failures >= self.failure_threshold:

self.open_since = time.time()

```

Fase 3: Generación → re-prompt con el error en contexto

Cuando el output del modelo es inválido, no relances la misma llamada con el mismo prompt. Eso es la definición de locura.

Usa el semantic retry: inyecta el mensaje de error en el contexto del modelo para que se autocorrija a nivel de prompt, no de excepción.

```python

def semantic_retry(model, request, error_message, max_attempts=3):

"""En vez de relanzar la misma llamada, inyecta el error en contexto."""

for attempt in range(max_attempts):

response = model.generate(

**request,

system_override=(

f"Tu respuesta anterior fue rechazada por el validador: {error_message}. "

f"Corrige el error y responde de nuevo."

)

)

validation = validate_response(response)

if validation.is_valid:

return response

error_message = validation.error # actualiza con el nuevo error

raise ManualEscalationError("3 intentos fallidos. Requiere revisión humana.")

```

El error #1 que comete todo el mundo: mezclar las recuperaciones. Re-planificar cuando había que hacer retry, o re-prompt cuando había que cortar la tool. Cruzar esos mecanismos produce el clásico bucle infinito de "recuperación" que repite el mismo fallo cuatro veces seguidas.

---

El ErrorClassifier Híbrido: Reglas Primero, LLM Solo para lo Ambiguo

"Vale, ¿y si uso un LLM para clasificar el error?" no. Un LLM-judge añade otro punto de fallo al sistema que está fallando.

El clasificador correcto es híbrido: reglas deterministas para lo que ya conoces, LLM solo para lo ambiguo, y siempre con un umbral de confianza que escale a humano en vez de auto-recuperar a ciegas.

```python

error_classifier.py

class ErrorClassifier:

"""Reglas deterministas primero. LLM-judge solo para lo ambiguo."""

def classify(self, exception, context) -> ClassificationResult:

1. Reglas deterministas: status codes, excepciones conocidas

if isinstance(exception, APITimeoutError):

return ClassificationResult(ErrorCategory.TRANSIENT, confidence=0.98)

if isinstance(exception, AuthenticationError):

return ClassificationResult(ErrorCategory.PERMANENT, confidence=0.99)

if exception.status_code in ERROR_MAP:

return ClassificationResult(ERROR_MAP[exception.status_code], confidence=0.95)

2. Output inválido detectado por el validador (no excepción)

if context.is_output_semantically_wrong:

return ClassificationResult(ErrorCategory.MODEL_OUTPUT_INVALID, confidence=0.9)

3. Solo lo ambiguo va al LLM-judge

if self._is_ambiguous(exception):

judge = self._llm_judge(exception, context)

if judge.confidence > 0.85:

return judge

CONFIANCE BAJA => escala a humano. Nunca auto-recuperar en duda.

return ClassificationResult(ErrorCategory.AMBIGUOUS, confidence=0.3)

return ClassificationResult(ErrorCategory.PERMANENT, confidence=0.5)

```

La regla de oro: auto-recuperar mal es peor que parar.

Un agente de pagos que "corrige" un fallo re-cobrando dos veces causa un desastre mayor que un halt con alerta. El diseño debe fallar hacia la seguridad: umbral de confianza bajo ⇒ escalado humano, no auto-recuperación temeraria.

---

El Decorator @recover: El Orquestador de la Robustez

Esta es la pieza que une todo. Un decorator que envuelve cada paso del agente, intercepta el fallo, lo pasa por el clasificador, elige el handler según la fase y registra la decisión.

```python

recover.py

def recover(phase: Phase):

"""Envuelve un paso del agente con clasificación + recuperación por fase."""

def decorator(fn):

@functools.wraps(fn)

def wrapper(args, *kwargs):

attempts = 0

for attempt in range(MAX_ATTEMPTS[phase]):

attempts += 1

try:

return fn(args, *kwargs)

except Exception as exc:

1. Clasifica ANTES de decidir cómo recuperarse

classification = classifier.classify(exc, build_context(fn))

2. Elige handler según categoría + fase

handler = HANDLER_MAP[(classification.category, phase)]

3. Éxito o escalado

result = handler.handle(exc, classification, args, *kwargs)

if result.is_resolved:

log_recovery(phase, classification.category, attempts)

return result.value

if classification.should_escalate_human():

raise ManualEscalationError(classification)

raise ManualEscalationError(f"{phase} failed after {MAX_ATTEMPTS[phase]} attempts")

return wrapper

return decorator

```

Este `@recover` no sustituye a la lógica de negocio. Es la capa de orquestación de la robustez — y aquí está el punto que conecta con todo lo que sabemos sobre agentes en 2026: el modelo subyacente es commodity. La ventaja competitiva está en la capa que decide cómo clasificar y recuperarse de un fallo.

El `ErrorClassifier` es esa capa para la fiabilidad.

---

Checkpointing: Reanudar, No Reiniciar

Para workflows largos — un agente de investigación que ejecuta 20 tools, un pipeline de ETL con 15 pasos — el checkpointing no es opcional.

```python

checkpointing.py

class WorkflowState:

"""Persiste el estado entre pasos para reanudar en vez de reiniciar."""

def __init__(self, store=memory_store):

self.store = store

@recover(Phase.TOOL)

def execute_step(self, step_id: str, run_id: str, fn, *args):

checkpoint = self.store.get(run_id, step_id)

if checkpoint:

return checkpoint.result # ya lo hicimos, recuperamos el resultado

result = fn(*args)

self.store.set(run_id, step_id, result) # persiste antes de seguir

return result

```

El patrón es simple: persiste el resultado de cada paso antes de pasar al siguiente. Si el workflow muere a mitad de camino, reanudas desde el último checkpoint, no desde el principio. Coste y latencia multiplicados por el número de pasos que NO necesitas re-ejecutar.

---

Instrumenta Cada Recuperación

Un agente que recupera sin registrar qué recuperó, cuántos intentos hizo y qué ruta tomó es un agente que nunca mejora.

```python

def log_recovery(phase, category, attempts, strategy):

telemetry.record({

"event": "agent_recovery",

"phase": phase, # plan | tool | respond

"category": category, # transient | permanent | ...

"attempts": attempts,

"strategy": strategy, # replan | retry | circuit_break | semantic_retry | escalate

"timestamp": time.time(),

})

```

Con esos datos aprendes cosas que ningún retry te enseña:

• Qué tools degradan la fiabilidad a los pocos días de estar en producción.

• Dónde está el límite correcto de tu circuit breaker.

• Qué categorías de error estás clasificando como `AMBIGUOUS` cuando en realidad son fallos de una dependencia que va a vuelta.

Ajustas umbrales con datos, no con intuición.

---

¿Un Modelo Mejor No Arregla Esto?

No. Y es la objeción que hay que cerrar ya.

Un modelo más capaz sigue siendo estocástico. Produce outputs malformados. Alucina tool args con argumentos plausibles. Y choca con errores de infraestructura — rate limits, tools caídas, esquemas que cambian — que ningún prompt resuelve.

La arquitectura de recuperación es ortogonal a la calidad del modelo. El fallo es estructural, no de capacidad.

Y el coste de no hacerlo bien es invisible: tu agente no se cae, se queda. Responde de forma convincente con datos equivocados. Genera un ticket de soporte con el campo de cliente vacío. Confirma una cita para una hora que no existe.

Eso no aparece en tus dashboards de uptime. Aparece en tu cola de soporte, seis semanas después.

---

La Frase Final

Construir agentes que sobrevivan a producción no es construir agentes que no fallen. Es construir agentes que detecten, clasifiquen y se recuperen de forma distinta según la fase en la que están.

La máquina de recuperación — clasificador híbrido, handlers por fase, decorator, checkpointing, telemetría — no es un afterthought. Es el feature de primer orden que separa una demo impresionante de un agente que aguanta el turno de noche de un sábado.

Tu modelo es commodity. Tu capa de clasificación y recuperación es tu ventaja.

*Construye esa capa como si tu agente fuera a fallar en el peor momento posible. Porque lo hará. Y la diferencia entre un incidente y un desastre es lo que pasa en los primeros 300 milisegundos después del fallo. *

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF

Crees que el pricing de tu SaaS es un problema de números. Que si comparas a la competencia, aplicas un margen razonable y encuentras "el punto de precio correcto", la conversión despega.

*Te has equivocado de diagnóstico.*

El 80% de los SaaS estructura sus planes de precios sin datos reales de uso. Y luego se pregunta por qué no convierte.

No es un problema matemático. Es un problema estructural. La mayoría de los "errores de pricing" no son malos cálculos — son apuestas a ciegas disfrazadas de decisión financiera. Mientras sigas tratando el problema como una ecuación de márgenes y multiplicadores, estarás puliendo una cifra que nunca tendrá el poder que le atribuyes, porque fue parida sin ninguna conexión con la realidad de tu producto.

---

El Precio No Es el Problema. La Falta de Observación Sí.

Antes de tocar una sola cifra, tu producto ya está hablando.

El 80% de las empresas define sus tarifas sin mirar el comportamiento de sus clientes. Sin saber qué features usan, con qué intensidad, ni qué patrones correlacionan con retención. Es el equivalente a un restaurante que fija el menú según el precio de los ingredientes en el mercado, ignorando por completo lo que sus clientes realmente piden. Puede que el cordero esté barato esta temporada, pero si tu clientela viene buscando el pescado, tendrás un menú impecablemente razonado… y una sala vacía.

La gravedad no es puntual. Es sistémica. No es que un 20% tenga datos perfectos y otro 20% parciales — es que cuatro de cada cinco deciden con cero evidencia. Cuando ese es el punto de partida, cualquier proceso de optimización posterior es optimizar sobre ruido. Es como calibrar una balanza que nadie ha comprobado: puedes ajustar los contrapesos todo lo que quieras, pero la medida de base sigue siendo falsa.

El problema más incómodo: el pricing basado en coste o en competidores es un enfoque desde arriba. Proyectas un precio a partir de inputs que ya puedes ver — tus costes, los precios ajenos — como si el valor que entregas fuera una constante conocida.

No lo es. El valor se descubre desde abajo, leyendo las señales que tus clientes emiten con cada clic, cada feature adoptada, cada upgrade o cancelación. Y para leer esas señales necesitas un sistema de observación, no una intuición.

Detente un momento y piensa en esto: tu producto lleva meses, quizá años, funcionando. Cada día, decenas o cientos de usuarios interactúan con él de formas que revelan exactamente qué valoran y qué ignoran. Esas señales existen. El problema no es que no estén ahí — es que no las estás registrando. Los datos están emitiéndose en este mismo instante, y tu equipo no tiene antena para recibirlos.

---

Por Qué el Enfoque Convencional Te Lleva a la Ruina

Mira esto con honestidad:

❌ Pricing desde arriba (el fracaso convencional): miras a la competencia, pones un precio parecido, inventas tres tiers con recuentos de features más o menos a ojo, y rezas.

✅ Pricing desde abajo (el enfoque que funciona): instrumentas el uso, observas qué features capturan valor real, agrupas clientes por comportamiento y dejas que los límites de cada tier se revelen solos.

La segunda opción casi nadie la hace. El 80% parte de cero datos — así que cualquier señal direccional ya es una mejora sobre el statu quo. No necesitas un espectacular sistema de analítica empresarial. Necesitas veinte minutos de trabajo para instrumentar dos o tres eventos y, a partir de ahí, empezar a ver patrones que tus competidores ni siquiera sospechan que existen.

Esto es exactamente lo que está cambiando el panorama de las plataformas tech más grandes. Cuando una empresa con el alcance de Meta afirma que los modelos de lenguaje le están permitiendo "acelerar el desarrollo de productos" y "entregar mejores resultados para las empresas", lo que está describiendo — en el fondo — es una capacidad de observar el comportamiento de sus usuarios a una escala y velocidad que antes era imposible. Los LLM les permiten entender qué contenido es realmente, generar mejores datos de entrenamiento y detectar tendencias sin intervención humana. Esa es la misma filosofía aplicada a escala industrial: decidir desde la observación, no desde la intuición.

Pensemos en el anchoring. La sabiduría convencional dice que el tier intermedio enmarca la percepción de los demás. Cierto a nivel psicológico. Pero aquí viene el giro: son los datos los que deciden dónde cae el ancla, no tu intuición.

Con datos de uso, puedes colocar el ancla donde se asienta el mayor cluster de power users — el segmento cuyo comportamiento ya señala el mayor valor percibido. El ancla deja de ser una corazonada y se convierte en un reflejo de la demanda real. Ya no preguntas "¿dónde debería estar el precio psicológicamente atractivo?", sino "¿dónde está el valor que mis clientes ya están consumiendo?". La respuesta a la segunda pregunta es infinitamente más potente en una conversación comercial.

---

El Feature Gating es Donde los Datos Rinden Más

Aquí es donde el 80% que no trackea se equivoca de forma más dolorosa.

La decisión de qué features gatear y cuáles dejar abiertas debería ser la más estratégica de tu pricing. Y sin datos, es literalmente un cara o cruz:

• Gatear una feature de higiene — la necesaria para la activación básica — genera churn. Si bloqueas lo que el usuario necesita para ver valor en el día uno, te marchas. Has construido un producto que exige un compromiso inmediato sin dar nada a cambio en las primeras sesiones, y el resultado es una puerta de salida mucho más ancha que la de entrada.

• Gatear una feature de valor — la que usan intensamente las cuentas más comprometidas — impulsa upgrades. Es la que convierte el free trial en pagador, porque genera el momento de fricción deseado: el usuario *siente* el límite precisamente porque ya ha experimentado el valor.

Sin tracking de uso es imposible distinguir ambas. Solo con datos puedes saber qué features correlacionan con conversión, cuáles con retención y cuáles son aspiracionales pero nunca se usan. Las features aspiracionales son especialmente traicioneras: ocupan espacio en tu tier más caro, hacen el plan parecer "completo", pero nadie las toca. Estás inflando el valor percibido de un plan que nadie necesita y, de paso, empujando a tus usuarios ligeros hacia un abono que jamás aprovecharán — y que tarde o temprano cancelarán.

Por eso la secuencia correcta es data-first. Antes de reestructurar tu pricing, antes de mover una cifra, antes de decidir qué va detrás de qué muro:

El tracking de uso es el Paso 1. Todo lo demás es output de ese análisis.

No lo conviertas en un proyecto de tres meses con dashboard de Power BI. Hazlo mínimo, hazlo mañana, hazlo con dos eventos. Lo que importa no es la sofisticación del sistema, sino empezar a acumular una serie temporal que puedas consultar cuando llegue la siguiente revisión de precios.

---

El Marco Data-First de Pricing: Instrumenta, Mide, Agrupa, Gatea

Llamemos a esto el Marco Data-First de Pricing. Son cinco pasos, en ese orden, sin saltarte ninguno.

Ten en cuenta que no estás construyendo "el pricing perfecto" en una tarde. Estás construyendo un sistema de aprendizaje continuo donde cada iteración de precios se apoya en los datos de la anterior. La primera vez que lo apliques puede que solo tengas un par de meses de telemetría — suficiente para dar un primer paso firme. Para la segunda o tercera revisión, tendrás patrones estacionales, correlaciones de retención y clusters bien definidos.

Paso 1: Instrumenta el tracking de uso ANTES de tocar ninguna cifra

No hace falta telemetría perfecta. Basta con definir tres o cuatro eventos núcleo que capturen valor real:

```javascript

// Eventos núcleo que definen el valor percibido

analytics.track('signup_completed', { plan: 'free', source: 'organic' });

analytics.track('feature_activated', { feature: 'reports', version: '1.4.2' });

analytics.track('value_milestone', { event: 'first_report_generated', time_to_value: 184 });

// El evento que correlaciona con retención real

analytics.track('session_intensity', {

frequency_days: 7,

heavy_usage_hours: 3.2,

core_features_used: ['reports', 'automation', 'export']

});

```

Estos eventos son tu sustrato. Sin ellos, cualquier decisión de pricing es especulación. Con ellos, tienes la base para todo lo demás.

Fíjate en el detalle del evento `value_milestone`: no trackeas "el usuario hizo clic en el botón de exportar", sino "el usuario generó su primer informe". Son cosas distintas. La primera es una interacción; la segunda es un hito de valor. Cuando diseñas tus eventos, pregúntate siempre: ¿esto mide lo que el usuario *hace o lo que el usuario logra*? Busca lo segundo.

Y no olvides el contexto. Un usuario que activa la feature `reports` en su primera sesión y otro que la activa tras tres semanas de uso están viviendo experiencias completamente distintas con tu producto. Tu tracking debe capturar ese contexto si quieres que los clusters revelen algo útil: el tiempo hasta el valor (time-to-value) es uno de los predictores más fuertes de retención que vas a encontrar.

Paso 2: Define el esquema de datos que necesitas recopilar

Pregúntate qué quieres saber antes de fijar un precio:

• ¿Qué features existen y quién los usa?

• ¿Con qué intensidad y frecuencia se usan?

• ¿Qué patrones de uso correlacionan con retención a 90 días?

• ¿Qué camino recorre un cliente desde activación hasta el momento de valor?

No necesitas todas las respuestas de golpe. Necesitas la infraestructura para empezar a responderlas en la siguiente revisión de precios.

Hay una distinción importante que conviene trazar aquí entre tres tipos de señales que vas a recopilar:

Señales de activación. Te dicen si un usuario nuevo está alcanzando el valor fundamental de tu producto. Son las más urgentes de instrumentar, porque sin ellas no puedes distinguir entre "el usuario no ve valor" y "el usuario no encontró el botón".

Señales de intensidad. Te dicen con qué profundidad usa tu producto alguien que ya está activado. Son las que alimentan tus clusters: frecuencia de sesión, horas de uso, colaboradores involucrados, automatizaciones ejecutadas.

Señales de retención. Te dicen qué comportamientos (o qué features) predicen que un cliente siga contigo al cabo de tres, seis o doce meses. Son las que convierten tu gating de features en algo estratégico: sabes qué proteger, qué exponer y qué sacrificar.

Paso 3: Agrupa clientes por uso observado para encontrar los límites naturales de cada tier

No impongas recuentos arbitrarios de features. Esto es el corazón del argumento:

```python

Agrupación por clúster de uso (pseudocódigo real)

from sklearn.cluster import KMeans

usage_features = df[['features_activated', 'intensity_hours', 'collaborators', 'automations_run']]

clusters = KMeans(n_clusters=3, random_state=42).fit(usage_features)

Los clusters te dicen DÓNDE caen los límites naturales

Cluster 0: activación básica, una feature, uso esporádico

Cluster 1: 3-4 features, uso regular, algún caso de uso avanzado

Cluster 2: power users, 6+ features, intensidad alta diaria

```

Esos límites son tus tiers. No los inventas: los descubres. Los clusters de comportamiento te dicen dónde termina un plan y empieza el siguiente.

El criterio de elección del número de clusters no debería ser cosmético — "tres tiers se ven bien en la página de precios" — sino predictivo. Prueba con 2, 3, 4 y 5 clusters, y fíjate cuál de ellos produce grupos con homogeneidad interna y diferencias significativas entre sí. Un cluster que contiene tanto a usuarios diarios como a usuarios de fin de semana no es un cluster útil: es un conjunto de etiquetas sin poder de segmentación.

Y aquí va un matiz importante: los clusters no deben fijarse únicamente por uso bruto, sino ponderando por retención. Un cluster con uso álgido pero churn del 60% a los 90 días es un cluster de humo — no un tier al que debas apuntar. Es el que te dice que algo en tu propuesta de valor para ese segmento está roto. El pricing, recordémoslo, es un sistema de observación, y los clusters son sus termómetros.

Paso 4: Elige el tier ancla y aplica feature gating según el valor consumido y medido

Con los clusters identificados, gatea las features de valor — las que usan intensamente los segmentos más comprometidos — no las que más te cuestan servir. Hay una trampa clásica aquí, y conviene llamarla por su nombre: el feature gating basado en coste de infraestructura. Gateas lo que te resulta caro *a ti servir, porque así "proteges margen". Es un comportamiento comprensible, pero estás protegiendo el margen equivocado: el coste que importa no es el tuyo, sino el valor percibido por el cliente*. Un servidor que consume 0,02 céntimos por petición puede ser el corazón del caso de uso de tus power users; si lo gateas mal, pierdes a todos.

El tier intermedio se convierte en tu ancla. Y con datos, su posición ya no es una corazonada: es donde se sienta tu mayor cluster de usuarios que pagan y usan con intensidad. Esa es la definición operativa del ancla perfecta: un segmento real, observable, medible — no un número redondo que te gusta.

Paso 5: Trata la reestructuración como un experimento continuo, no una edición anual

Tras el lanzamiento, mide conversión, adopción de features y movimientos upgrade/downgrade. El pricing deja de ser una decisión anual de finanzas y se convierte en un bucle de producto permanente.

Aquí es donde el marco conecta con lo que está ocurriendo en el ecosistema tech en general. La velocidad de iteración que permiten las nuevas herramientas — impulsadas por modelos de lenguaje que aceleran el desarrollo de producto, como describe Meta en su propia estrategia — significa que el pricing debe tener la misma agilidad que el producto al que sirve. Si tu producto puede evolucionar en semanas gracias a la IA, y tu pricing solo se revisa una vez al año "porque es lo que se hace", tienes un desajuste estructural: estás fijando el precio de algo que ni siquiera es el mismo producto que tendrás dentro de seis meses.

Cada cambio futuro de precios debería ir precedido de una revisión de datos. El pricing pasa a ser un experimento en marcha, no una hoja de cálculo cerrada. Y como en todo experimento, hay que predefinir cuáles serán los criterios de éxito y fracaso antes de lanzarlo: "si la conversión free→paid no sube un 2% en 60 días, revertimos". Eso te protege de la tentación de justificar resultados mediocres con narrativas post-hoc.

---

Las Objeciones Que Te Estás Haciendo Ahora Mismo

"Somos cuatro, no tenemos infraestructura de analítica." No hace falta. Trackea dos o tres eventos núcleo antes de la siguiente revisión de precios. Dado que el 80% parte de cero datos, cualquier señal direccional ya te coloca por delante de la mayoría. Además, el coste de oportunidad de esta objeción es enorme: cada semana sin tracking es una semana de decisiones tomadas a ciegas. Si tu producto tiene un mínimo de tracción, los datos que estás ignorando valen más que cualquier consultor de pricing que puedas contratar.

"Anclarme en competidores es más seguro." Anclarse en competidores asume que tu perfil de uso y tu entrega de valor coinciden con los suyos. Eso rara vez es cierto. Tu producto tiene features propias, flujos de activación distintos y un público que lo usa de maneras que el competidor ni imagina. Los datos de uso te dan la licencia para desviarte con fundamento, y para defender esa desviación en cada conversación comercial con evidencia observada, no con sensaciones. "Nuestros clientes de mayor retención usan la automatización cuatro veces por semana" pesa infinitamente más que "nuestro competidor cobra 49 €".

"Reestructurar tiers va a enfadar a los clientes existentes." Se resuelve con grandfathering y rutas de migración. Y sobre todo: los datos de uso te permiten identificar qué clientes existentes consumen de más o de menos antes de forzar ningún movimiento. Un cambio basado en datos es infinitamente más fácil de comunicar, justificar y defender ante el cliente que uno salido de una intuición. El cliente puede no estar de acuerdo con el nuevo precio, pero le hablas con evidencia: "hemos visto que tu cuenta consume el equivalente a tres planes Enterprise; te ofrecemos esta ruta de migración". Eso es otra conversación.

---

La Inversión Real del Pricing

La pregunta correcta nunca ha sido "¿cuánto cobramos?". Es "¿qué sabemos de cómo usan esto nuestros clientes?".

Porque el pricing no es una decisión de entrada tomada en una hoja de cálculo. Es un output de la analítica de uso. Y la estructura de tus tiers no se impone desde arriba con multiplicadores — se descubre desde abajo con señales observables.

Lo mismo que está pasando en el desarrollo de producto — donde las empresas que observan el comportamiento de sus usuarios y dejan que los datos guíen la iteración están ganando la partida a las que construyen desde la intuición — está pasando en el pricing. Es el mismo desplazamiento de mentalidad, aplicado a una función que históricamente se ha tratado como un problema de finanzas en lugar de un problema de producto.

Mientras el 80% pregunta cuánto cobrar, el 20% que instrumenta, mide y observa acumula una ventaja que ninguna hoja de cálculo puede replicar.

El pricing no es un número. Es un sistema de observación que aún no has construido.

Empieza por ahí. Antes de tocar una sola cifra.

Lee el artículo completo en brianmenagomez.com

Más sobre mis servicios en brianmenagomez.com

Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF