El agente que entra sin instrucciones

El 1 de junio de 2026 dejé el conector MCP vivo en claude.ai. Está abierto a usuarios gratuitos y a usuarios premium, y desde ese día hay una pregunta a la que no he dejado de darle vueltas: ¿qué ve un agente que entra aquí por primera vez?

Ve una lista de herramientas. Cada una con su nombre y una frase de descripción. Y poco más.

Esa lista le sirve para saber qué puede llamar. No le sirve para saber si merece la pena llamarlo. Son dos cosas distintas y yo las había tratado como una sola.

Un agente así no sabe cuántas cosas puedo responderle, no sabe cuáles se solapan y, sobre todo, no sabe de cuándo son los datos que le voy a devolver. Ese último punto es el que me preocupaba de verdad. Un agente que tiene que decidir si un dato le sirve necesita saber si es de esta semana o de hace medio año. Si no lo sabe, o confía de más o avisa de menos. Las dos salidas son malas.

Un dato viejo presentado como actual es una alucinación con papeles. Y no la comete el modelo: la cometo yo, por no decirle de cuándo es lo que le sirvo. Al contrario también falla: un agente que no sabe la fecha tiende a ser cobarde, a dudar de un dato bueno, a responder con un «depende» que no ayuda a nadie.

Lo que probé primero: escribir mejor

Mi primer reflejo fue el de siempre: si el agente no sabe qué hay dentro, se lo cuento. Me puse a documentar. Una lista de las funciones disponibles, con una línea por cada una explicando qué devuelve y qué necesita. Un documento ordenado, escrito por mí, en el sitio donde yo escribo.

El razonamiento parecía sólido. La documentación es donde un humano aprende a usar un sistema; tarde o temprano un agente pasará por ahí. Documento una vez y el problema queda resuelto para siempre.

Se sostiene hasta que lo piensas dos veces.

El fallo no estaba en el texto, estaba en el sitio

El problema de documentar era doble, y ninguno de los dos tenía que ver con la calidad de lo que escribía.

Primero: el agente no pasa por donde yo escribo. Un agente no lee mi documentación, llama a herramientas. Si lo que necesita saber no está al otro lado de una llamada, para él no existe. Estaba describiendo la casa en una habitación a la que el interesado no tiene llave.

Segundo: un documento es una copia, y una copia se desincroniza. Cada vez que añado una función o cambio lo que devuelve otra, tengo que acordarme de volver a redactar el texto. Al principio te acuerdas. Al cuarto cambio, no. Cada RPC nueva que publicaba era una línea más que sostenía a mano: el texto crecía en la misma proporción que mi deuda. Estaba dibujando a mano el mapa de un territorio que se movía solo.

Y quedaba la pregunta que ningún texto podía contestar: «¿de cuándo son estos datos?». Eso no lo sabe un documento. Lo sabe la base.

La base se describe a sí misma

La salida fue dejar de escribir sobre la base y hacer que la base hablara. Añadí una RPC nueva: `describe_conversor()`.

`describe_conversor()` no devuelve epígrafes ni códigos. Devuelve un JSONB auto-descriptivo, escrito para que lo lea un agente. Dentro van dos cosas:

• el inventario de RPC a las que puedo responder, es decir, qué sabe hacer la base;

• las marcas de tiempo de frescura de los datos, es decir, de cuándo es lo que te voy a devolver.

Juntas, esas dos piezas contestan a las dos preguntas que un agente se hace antes de fiarse de una herramienta: qué sabe hacer quien está al otro lado y si lo que le va a contar sigue siendo cierto. La primera es cobertura; la segunda es confianza. Sin la segunda, la primera sirve de poco.

Y hay algo mejor que el contenido: de dónde sale. Un agente que acaba de conectarse descubre solo qué hay aquí. No necesita integración previa, no necesita que yo le cuente nada y no necesita acertar por prueba y error. Pide la descripción y recibe el mapa. Y como ese JSONB se construye leyendo el catálogo de la base, no es una copia: es una lectura. No hay nada que mantener a mano, así que no hay nada que se quede viejo.

Reforcé la misma idea por otro camino, el que tenía más a mano: los comentarios del catálogo. Con `COMMENT ON` dejé descripciones pegadas a las tablas, a las columnas y a las funciones. El texto vive junto al objeto que describe, en el mismo sitio, y viaja con él cuando el esquema cambia. Y como el que describe y el descrito son el mismo esquema, el comentario no puede mentir sobre lo que la base hace: si cambia la función, el comentario está ahí mismo, a la vista, en la misma revisión.

Para separar audiencias, marqué esos comentarios con una etiqueta: `[agent]`. Lo que lleva esa marca está escrito para que lo lea un agente, no un humano curioseando la estructura. Las dos audiencias no necesitan el mismo texto, y mezclarlas estropea las dos. Podría haber escrito dos documentos separados, uno para cada una, pero entonces volvía al problema de antes multiplicado por dos. La etiqueta consigue lo mismo sin duplicar: un solo comentario por objeto, marcado, y quien lo lee decide si le concierne.

Qué aprendí

Me quedo con una regla: si quieres que un agente use tu sistema sin que nadie le explique nada, no le des documentación — dale una función que se describa a sí misma.

La descripción de un sistema tiene que vivir donde vive el sistema. Todo lo demás es una copia que envejece. Y la frescura de los datos no es un detalle de operación: es información de primera, tan importante como el propio dato. Un agente que sabe qué sabe la base y de cuándo lo sabe puede decidir. Uno que no lo sabe, adivina.

Aprendí la lección con un fallo pequeño y tonto, de esos que no rompen nada y por eso tardas en verlos: había escrito la respuesta en el sitio equivocado. El contenido estaba bien; la ubicación, no.

El conector sigue vivo en claude.ai desde aquel 1 de junio, para cuentas gratuitas y de pago. Si construyes agentes y quieres ver cómo se describe la base por dentro:

https://www.conversoriaecnae.es/mcp

Dos rutas que parecían el mismo sitio

Cuando conecté mi servidor MCP a claude.ai me encontré con dos cadenas que parecían lo mismo y no lo eran.

El conector MCP es la pieza que deja a un agente en claude.ai consultar datos fiscales sin montar su propia integración. Para que un agente lo use hay OAuth por medio: un token, un metadato de recurso, una validación. Y fue montando esa parte de OAuth donde topé con las dos cadenas.

La URL de transporte del conector es `/api/mcp/mcp`. Esa es la que recibe las peticiones de verdad: la ruta por la que un agente entra y consulta la base de datos fiscal. Si entras al `/api/mcp` a secas, la API contesta un 404. Le falta el segmento `[transport]`. Sin ese último tramo, la ruta directamente no existe.

El identificador de recurso OAuth, en cambio, es a propósito el `/api/mcp` a secas. Ese es el `aud` del token y el `resourceUrl` que publico en mi PRM, el Protected Resource Metadata.

Conviven, entonces, dos cadenas casi idénticas. Una termina en `/mcp/mcp`; la otra, en `/mcp`. Y lo primero que pensé fue: «esto es un bug».

Por qué quise armonizarlas

Parecía el descuido clásico. Dos rutas que se parecen tanto que una tenía que ser un error de la otra. ¿Quién deja a propósito un identificador sin el último segmento?

Mi razonamiento era lineal. Si el identificador OAuth es `/api/mcp`, la URL de transporte debería ser `/api/mcp`. O al revés: si el transporte es `/api/mcp/mcp`, el identificador debería ser `/api/mcp/mcp`. Cualquier opción, con tal de no dejar dos cadenas que a simple vista no coinciden.

La tentación tenía nombre propio: armonizar. Un solo cambio, dos rutas consistentes, y el código queda más limpio. Al fin y al cabo, ¿no es lo mismo un recurso y el sitio donde se sirve ese recurso? Si apuntas al mismo lugar, ¿por qué escribirlo distinto?

Estuve a punto de hacerlo. La intención era buena; el modelo mental, no. Lo peor es que la decisión no venía de leer el RFC, sino de una corazonada visual: dos cadenas que no cuadran, por definición, tenían que ser un descuido.

El error que no llegué a cometer

Y aquí está el fallo, que por suerte no llegó a producción.

El `/api/mcp` a secas devuelve 404. No es que apunte mal ni que esté roto: es que no es un endpoint. Es una identidad lógica, no una ruta de red. Si lo armonizo para que coincida con la URL de transporte, estoy mezclando dos cosas que no son lo mismo, y el resultado no se vuelve más limpio: se vuelve incorrecto.

Peor todavía: armonizar ambas habría roto el conector en vivo. claude.ai no compara las cadenas por su parecido ni por cómo se leen de izquierda a derecha. Valida el identificador contra el PRM. Si yo cambio el identificador a `/api/mcp/mcp` para que «cuadre» con la URL de transporte, el PRM deja de casar, la validación falla y la conexión se cae.

El bug no estaba en el código. Estaba en mi modelo mental. Asumí que una ruta de red y un identificador de recurso debían ser la misma cadena. No lo son. Y de haber aplicado el cambio sin pararme a entender por qué existían dos cadenas, habría roto algo que ya funcionaba.

La distinción que lo resuelve

La salida vino de los RFC. Un identificador de recurso OAuth — el `aud` del token y el `resourceUrl` del PRM — es un identificador de recurso en el sentido de RFC 9728 y RFC 8707. Una identidad lógica. No es el endpoint de red por el que viajan los bytes.

El matiz que lo aclara todo está en cómo OAuth separa el «quién» del «por dónde». RFC 8707 define cómo un cliente indica a qué recurso va dirigido el token que pide. RFC 9728 define cómo el servidor de recursos publica su metadato para que el cliente lo descubra. En los dos casos, el identificador de recurso es eso: un identificador, un nombre con el que OAuth se entiende a sí mismo. No una ruta de transporte.

Son dos preguntas distintas, y conviene no confundirlas.

El endpoint de transporte `/api/mcp/mcp` responde a «¿por dónde entro?». Dice la ruta concreta, incluido el segmento `[transport]`, por la que llega la petición. Sin ese segmento la ruta no resuelve, y por eso el 404.

El identificador `/api/mcp` responde a otra cosa: «¿qué recurso estoy autorizando?». El `aud` del token dice para quién se emitió ese token; el `resourceUrl` del PRM dice qué recurso es este para el mundo OAuth. Es un nombre, no una dirección.

Dicho más claro: la URL de transporte es una dirección; el identificador de recurso es un nombre. Una dirección y un nombre pueden no coincidir y aun así referirse a lo correcto. En mi conector, el recurso lógico se llama `/api/mcp` y su ruta de transporte es `/api/mcp/mcp`. Las dos conviven porque cada una responde a una pregunta diferente.

Qué aprendí

Me quedé con una regla que ahora aplico a cada integración OAuth que toco: la URL de transporte no es el identificador de recurso. El `aud` y el `resourceUrl` son identidad, no enrutamiento.

Cuando veo dos cadenas que «deberían» coincidir y no coinciden, ya no salgo a armonizarlas. Primero me pregunto si estoy comparando dos conceptos que, por diseño, no tienen por qué ser la misma cadena. Casi siempre, la respuesta está en el RFC.

Fue un bug que no llegué a meter. Y precisamente por eso es de los que más me ha enseñado: no me corrigió el código, me corrigió la forma de leerlo. La próxima vez que dos rutas no cuadren, antes de tocarlas voy a preguntarme qué está respondiendo cada una.

Si construyes agentes y quieres ver el conector que me dio esta lección, está aquí:

https://www.conversoriaecnae.es/mcp

No olvidan porque el modelo sea limitado. Olvidan porque los modelas como un chat al que le vas cortando el historial.

Miras tu código y ves un `messages[]` que crece. Cuando se llena, lo truncas o le pides al LLM que resuma. Repites. Eso es lo que el 90% de los agentes en producción hacen hoy — y el resultado es amnesia estructural.

*El problema no está en el LLM. Está en la arquitectura de su memoria. *

Toda la industria corre hacia ventanas de contexto más grandes pensando que ahí se resuelve. No es verdad. Agrandar la ventana no da al agente la capacidad de distinguir qué merece ser recordado mañana. Todo pesa igual en un buffer lineal.

El Fallo no es Técnico. Es de Diseño

La mayoría de los frameworks te dan un `messages[]` plano. Crees que el modelo "no le cupo el contexto". Los comienzas a resumir. Y cuando resumes, destruyes granularidad episódica — pierdes exactamente lo que un agente necesita para responder "¿qué decidimos el martes?".

Una ventana de un millón de tokens tampoco es memoria. Es un espacio de trabajo gigante.

Contexto ≠ memoria. El contexto es un espacio de trabajo de un solo turno. La memoria es lo que persiste cuando el contexto desaparece. Confundirlos es la razón de que se invierta en prompts cada vez más largos en lugar de en sistemas de almacenamiento y recuperación.

Un buffer gigante degrada latencia, encarece cada llamada y — lo más importante — no jerarquiza. El dato crítico compite con el ruido al mismo peso.

❌ La sabiduría convencional: "El agente no recuerda porque el contexto no le cabía. Meto más tokens."

✅ La realidad: "El agente no recuerda porque lo diseñé como un chat lineal sin política de olvido ni recuperación."

La Memoria Humana no es un Bloc de Notas

La psicología distingue tres sistemas. Tus agentes necesitan los mismos tres con velocidades de olvido distintas:

1. Memoria de trabajo — volátil, se evicta por presión de tokens.

2. Memoria semántica — hechos consolidados ("el usuario prefiere Python", "odia los emails largos").

3. Memoria episódica — eventos con timestamp ("el martes desplegamos el webhook y falló").

Recuperar un episodio con un embedding semántico aproximado pierde lo que hace episódico a un episodio: su secuencia exacta y sus consecuencias. Por eso esta capa necesita un log estructurado y queryable, no otra búsqueda vectorial.

Diseña el Framework de 3 Capas con Controlador de Memoria

Este es el patrón que separa una demo de un producto. Un agente sin controlador vuelca todo el historial. Uno con controlador inyecta contexto curado en cada turno.

Paso 1: Audita tu Amnesia Actual

Mira tu agente. ¿Guarda estado como un único array que se trunca o resume?

Documenta qué información concreta se pierde cuando el buffer se llena. Identidad del usuario. Decisiones tomadas. Compromisos a futuro. Preferencias declaradas.

Esa lista de pérdidas es tu spec de memoria.

Paso 2: Separa las Capas con un MemoryManager

Prohibe que el agente escriba directo en el historial. Define un `MemoryManager` que posea tres stores independientes:

```python

class MemoryManager:

def __init__(self):

self.working = WorkingMemory(max_tokens=4000) # Volátil, presupuesto de tokens

self.long_term = VectorStoreBackedMemory() # Hechos consolidados, persistente

self.episodic = EventLogBackedMemory() # Eventos append-only con timestamp

def write(self, entry: MemoryEntry, layer: str):

El agente NUNCA escribe directo al historial del LLM.

if layer == "working":

self.working.upsert(entry)

elif layer == "long_term":

self.long_term.consolidate(entry)

elif layer == "episodic":

self.episodic.log(entry)

def read_for_context(self, query: str, budget: int) -> list[str]:

return self.controller.assemble(query, budget)

```

El agente escribe en la capa correcta. Nada de `list.append(role, content)` directo.

Paso 3: Working Memory con Eviction por Tokens, no por Mensajes

Un buffer circular con eviction por peso de tokens real. Usa `tiktoken` en vez de contar mensajes:

```python

import tiktoken

enc = tiktoken.encoding_for_model("gpt-4o")

class WorkingMemory:

def __init__(self, max_tokens: int = 4000):

self.max_tokens = max_tokens

self.anchor = {} # Estado esencial: nombre, task context. NUNCA se evicta.

self.buffer = []

def add(self, message: dict) -> list[dict]:

self.buffer.append(message)

return self._evict_if_needed()

def _evict_if_needed(self) -> list[dict]:

token_count = sum(len(enc.encode(m["content"])) for m in self.buffer)

while token_count > self.max_tokens and self.buffer:

self.buffer.pop(0) # Evicta los más antiguos excepto el anchor

token_count = sum(len(enc.encode(m["content"])) for m in self.buffer)

return self.anchor_slot() + self.buffer

```

El anchor es el ingrediente crítico. Un slot protegido con el estado esencial del usuario y la tarea que sobrevive a cualquier truncado. Sin él, cuando el buffer se evicta pierdes quién es el usuario y qué estaba haciendo.

Paso 4: El Ciclo de Consolidación

Al final de cada sesión (o al detectar un hito), un paso de reflection extrae hechos long-term y resume eventos. No esperes al "resumir por token" reactivo. Consolida proactivamente.

Extrae con el LLM: "Dado este historial, ¿qué hechos sobre el usuario debemos persistir? ¿Qué eventos merecen registro episódico?".

Persiste los hechos en pgvector o Chroma con metadata de recencia. Registra los episodios en un log estructurado:

```json

{

"event_id": "9f4c2a1e",

"timestamp": "2026-09-08T14:32:11Z",

"session_id": "s-7712",

"user_id": "u-8821",

"action": "deploy_webhook",

"tool_call": "vercel_deploy",

"outcome": "failure",

"error": "INVALID_ENDPOINT_URL",

"user_feedback": "vale, prueba otra vez con la URL corregida",

"next_action": "retry_with_fixed_url"

}

```

No texto libre. Campos queryables. Así el agente responde "¿qué hicimos la semana pasada?" con un SQL o query estructurada, no con recuperación semántica difusa que confunde episodios.

Paso 5: El Controlador de Recuperación — el Componente que Casi Nadie Diseña

El controlador decide en cada turno si consulta long-term/episodic, con qué query y cuántos resultados. No vuelca contexto — lo cura.

```python

class MemoryController:

def __init__(self, memory: MemoryManager):

self.memory = memory

def decide(self, user_message: str, current_context: str) -> list[str]:

retrieval_intent = classify(user_message) # ¿necesita histórico? ¿es continuidad o nueva tarea?

if retrieval_intent == "continuity":

return self.memory.long_term.query(user_message, top_k=5)

elif retrieval_intent == "history":

¿Qué hizo el agente hace X días, con qué resultado?

return self.memory.episodic.query(

f"SELECT * FROM events WHERE session_id = ? AND timestamp > ? ORDER BY timestamp",

params=[last_session_id, last_week]

)

else:

return [] # Nueva tarea atómica. No necesitas pasado.

```

La respuesta a RAG aquí es importante: RAG resuelve memoria semántica de documentos, no memoria de interacción.

Un agente que usa RAG para recordar lo que el usuario le dijo ayer está mal equipado. Los hechos conversacionales son de alta recencia y alta especificidad. No viven en un corpus indexable — viven en un flujo de eventos.

Por eso la arquitectura híbrida gana: semántica para hechos consolidados, estructurada (SQL/JSONL) para eventos episódicos.

Mide lo que Antes Era Invisible

El controlador hace la memoria testeable. Puedes inyectar eventos conocidos y verificar recuperación — imposible con un buffer opaco.

Mide dos métricas:

1. Tasa de "¿recuerdas…?" fallidas — cuando el usuario pregunta "¿qué decidimos la semana pasada?", ¿responde el agente o improvisa?

2. Tokens de contexto por turno — si añades memoria curada, el presupuesto de contexto debería *bajar*, no subir.

La mejora debe verse en ambas. Si sólo baja una, tu controlador está mal calibrado.

La Objeción del Millón de Tokens

"¿Para qué complicarme con tres capas si meto todo el historial?"

El coste real: degradación de latencia y atención en prompts largos. Ruido que compite con la instrucción actual. Y sobre todo — "todo el historial" no es memoria selectiva.

El agente no distingue el dato crítico del ruido. Sigue sin poder responder "¿qué decidimos el martes?" de forma fiable porque en un buffer lineal no hay jerarquía de relevancia.

La amnesia del 90% de los agentes es una decisión de diseño, no una maldición del modelo. Y por tanto es una ventaja competitiva disponible para quien la resuelva.

Los agentes que persistan contexto entre sesiones —con consentimiento y gobernanza de datos explícitos— podrán ofrecer continuidad real. Menos repetición de preferencias. Menos re-explicación de contexto. Ahí es donde los usuarios notan la diferencia entre una herramienta y un asistente.

Gobernanza y Testing: La Memoria Te Hace la Vida Más Fácil, no Más Difícil

"Persistir memoria es un riesgo de privacidad. ¿Cómo reproduzco un bug si el agente depende de estado previo?"

El diseño explícito responde a ambas.

• Define qué se persiste, con qué consentimiento y qué política de retención/borrado. No es un extra — es parte de la spec.

• Un event log inyectable es más fácil de depurar que un historial opaco. Reproduces un bug cargando un estado conocido y verificando la recuperación.

• Implementa un modo "memoria desactivada" como herramienta de diagnóstico. Si el agente falla con memoria pero funciona sin ella, el bug está en tu controlador de consolidación o recuperación — no en el modelo.

Los Tres Takeaways

1. Contexto no es memoria. El contexto es temporal y caro. La memoria persiste y se curó. Deja de invertir en ventanas gigantes y empieza a diseñar almacenamiento y recuperación.

2. Tres capas con políticas de olvido distintas. Working (evicta por tokens, protege el anchor), long-term (consolida hechos), episodic (log estructurado append-only con timestamp).

3. El controlador de memoria es el producto. Decide qué escribir, qué recuperar y cuándo. Un agente sin controlador vuelca contexto; uno con controlador actúa con contexto suficiente y nada más.

La próxima vez que tu agente "no recuerde quién eres", no culpes al modelo. Mira tu `messages[]` y pregúntate si lo diseñaste como un chat o como un sistema de memoria. La diferencia es la que hay entre una herramienta que responde y un asistente que te conoce.

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 productizar es empaquetar. Definir alcance, estandarizar la entrega, fijar el precio y listo.

*Te has equivocado de diagnóstico.*

Eso no es productizar. Es comprimir. Y comprimir no crea producto: crea un servicio más pequeño con una etiqueta más bonita. Llevo cuatro años enviando software en España y he visto docenas de operadores —agencias digitales, freelancers, consultores técnicos— caer en la misma trampa. Cogen el servicio que ya venden, le cortan el alcance, le ponen precio fijo y lo llaman "producto". Lo que han construido es un acuerdo de no-matar-su-margen, no algo que escale.

La cifra del 90% es una hipótesis provocadora, no una estadística con fuente. Lo digo con transparencia antes de que lo preguntes. Pero se comprueba de forma cualitativa: mirad vuestro sector y contad cuántas "productizaciones" se describen por su entregable y su alcance —lo que las delata como servicios disfrazados— frente a cuántas se describen por el resultado que el comprador ya reconoce como problema.

El patrón es idéntico al que desmonté sobre la "opción segura" al construir con Next.js: la decisión prudente —empaquetar lo que ya haces— es la que garantiza la irrelevancia. La decisión incómoda —declarar categoría— es la única con capacidad de escalar.

El Problema: Comprimir Nunca Crea Categoría

Cuando "productizas" recortando alcance y fijando condiciones, aceptas la casilla competitiva que ya definió el incumbente. El cliente te compara con la alternativa preexistente en sus propios términos. Qué incluye. Qué no incluye. Cuánto cuesta frente a la otra agencia.

Tu oferta se convierte en un commodity negociable. Peleas dentro de la casilla del otro, con sus reglas, su lenguaje y sus métricas. Y en esa pelea, el incumbente siempre gana: tiene más casos, más reputación y más presupuesto.

❌ El servicio comprimido:

→ "Auditoría de SEO en 14 días"

→ "Paquete de branding para pymes"

→ "Landing page productizada en 10 días"

✅ La categoría:

→ "El sistema que convierte visitas en citas para clínicas dentales"

→ "La garantía de que tu web no se caiga en el Black Friday"

→ "El método que sustituye al comercial que no contesta"

¿Veis la diferencia? La primera lista describe entregables. Compite con todas las auditorías, todos los paquetes de branding y todas las landing pages del mercado. La segunda lista describe resultados que el comprador ya reconoce como problema —y que no sabe cómo nombrar cuando va a comprar.

La categoría redefine el eje de comparación. El servicio viejo deja de ser "lo mismo pero más caro" y pasa a ser "la forma antigua de obtener el resultado". El cliente deja de preguntar "¿qué incluye y cuánto cuesta?" y empieza a preguntar "¿puedo permitirme no tener este resultado?".

El Trabajo Fantasma Como Activo Estratégico

La intuición dominante dice que todo lo que entregas sin facturar ni nombrar es margen regalado o ineficiencia.

La lectura de categoría lo invierte: el trabajo fantasma es la evidencia empírica del resultado que ya produces. Es lo único que demuestra que tu categoría existe antes de que la nombres.

Pensad en ello. ¿Qué hacéis hoy que el cliente no ve en la propuesta? ¿Qué arregláis que no está en el alcance? ¿Qué garantizáis que no podrías comprar por separado en la competencia? Ese trabajo invisible es la materia prima de la categoría.

Un ejemplo real. Tenía una gestoría como cliente en España que vendía "asesoría fiscal". Cuando audité su trabajo fantasma, descubrí que su valor real no era presentar los impuestos —eso lo hace cualquiera— sino que el autónomo dejaba de dormir mal en abril. Ellos absorbían la ansiedad regulatoria, las cartas de Hacienda y los sustos de última hora. Su productoizado no debería llamarse "asesoría fiscal": debería llamarse "la garantía de que Hacienda no te robe el sueño en abril".

Quien audita primero, nombra primero. Quien nombra primero, define las reglas.

El caso Graza es el ejemplo perfecto fuera de los servicios. La marca de aceite de oliva DTC no se posicionó como "otra marca de aceite con suscripción". Se posicionó como la comunidad que convierte a sus clientes en nodos de adquisición —con un programa de referidos que, según sus propios datos, desplomó el coste de adquirir cada cliente frente al paid media. No compitieron contra las marcas de aceite. Compitieron contra la ausencia de esa comunidad. Esa es la jugada de categoría, no de empaquetado.

Cómo Construir Categoría, No Eslogan

Aquí está el error que comete casi todo el mundo: intentar el camino corto. Rebautizar el servicio, subir el tono del marketing y esperar que el naming haga el trabajo.

La categoría muere en la primera entrega que no cumple el resultado prometido. Por eso el orden importa más que el nombre.

Paso 1: Audita tu trabajo fantasma

Haz inventario de todo lo que entregas, asesoras, garantizas o arreglas que el cliente no ve en la propuesta ni podría comprar por separado. Ese trabajo invisible es la evidencia de tu categoría antes de que exista. Pregunta a tus últimos cinco clientes: "¿Qué fue lo que más valoró de trabajar conmigo?" — y busca lo que no aparece en tu factura.

Paso 2: Nombra la categoría por el resultado, no por la entrega

Si tu oferta se llama "auditoría técnica" describes un entregable —y compites con todas las auditorías del mercado. El test: el nombre debe ser el que tu comprador usaría en una conversación interna con su jefe o su socio. No el que usa tu factura.

Paso 3: Declara el marco competitivo

Define quién es la alternativa real. No es otra agencia ni otro paquete. Es el statu quo: no hacer nada, hacerlo con el servicio viejo, hacerlo in-house. Al nombrar al incumbente como alternativa, dejas de ser comparado por precio dentro de su categoría. Pasas a ser la referencia de un problema que antes no tenía nombre de compra.

Paso 4: Fija la métrica de tu categoría

Elige un indicador de resultado que solo tu categoría puede prometer y medir —y que el servicio comprimido no sabe operar porque está organizado por horas o por entregables. Esa métrica es el ancla que hace verificable la categoría. Si no puedes medir el resultado de forma observable, no tienes categoría: tienes un eslogan.

Paso 5: Cierra el bucle con mecánica de producto

El naming y el marco competitivo sin entrega repetible, puntos de entrada claros y resultados observables quedan en humo. La categoría se sostiene cuando el proceso productizado hace verdad la promesa de resultado en cada ciclo de entrega. Este es el punto donde la mayoría abandona —y donde se separan los que crean categorías de los que pintan anuncios.

Las marcas que ganaron en DTC durante 2026 no lo hicieron por tener el mejor empaque. Won't Stop, la marca de running que pasó de cero a números estratosféricos en 36 meses, no se posicionó como "otra marca deportiva con suscripción". Se posicionó como la categoría del corredor serio que los minoristas generalistas ignoran. Su CEO lo dijo literalmente: "No construimos un negocio de suscripción. Construimos una cultura de membresía que resulta tener un sistema de cobro pegado". Eso es declarar categoría —no vender un servicio con recurrencia mensual.

Sobre las Objeciones Que Ya Estás Pensando

"Esto es branding vacío: cambiar el nombre no cambia lo que entregas."

Concedido. Y por eso el framework arranca en el paso 1, con la auditoría del trabajo real, no con el naming. La etiqueta debe ser la consecuencia de un proceso que ya funciona, no su sustituto. Si cambias el nombre sin cambiar la mecánica de entrega, tienes exactamente lo que describes: humo.

"Crear categorías es para grandes: eso requiere presupuesto de marca tipo Salesforce o HubSpot."

Falso. La creación de categoría a pequeña escala no exige medios masivos. Exige cambiar el marco de comparación —nombrar al incumbente como alternativa— y fijar la métrica del resultado. Ambos movimientos se hacen en la propuesta comercial, en la página de venta y en el primer discovery call. No en una campaña de marca de seis cifras. El pequeño operador tiene una ventaja que Salesforce no tiene: velocidad para ejecutar el cambio de marco esta semana.

"El 90% es una cifra sin fuente: la estáis inventando."

Sí, es una hipótesis provocadora, no un estudio. Pero en lugar de descartarla, haced la prueba. Examinad las productizaciones de vuestro sector —las que se anuncian, las que se venden, las que fracasan— y contad cuántas se describen por entregable y alcance frente a cuántas se describen por un resultado que el comprador ya reconoce como problema. El resultado de esa prueba cualitativa os dirá si el 90% se queda corto o se queda largo.

El Marco de Categoría por Resultado

Este es el framework completo en cinco pasos. Llamadlo El Marco de Categoría por Resultado si os sirve para recordarlo:

1. Audita el trabajo fantasma — inventaría el outcome que ya produces de forma invisible. Es tu evidencia antes del nombre.

2. Nombra por el resultado — el nombre debe ser el que tu comprador usaría en una conversación interna, no el de tu factura.

3. Declara al incumbente — tu alternativa no es otra agencia, es el statu quo. Nómbralo.

4. Fija la métrica de categoría — un indicador de resultado que el servicio por horas no sabe operar. Es tu ancla verificable.

5. Cierra con mecánica de producto — proceso repetible, puntos de entrada claros, resultados observables. Sin esto, es eslogan.

La idea del producto escalable no es vender el mismo servicio más barato. Es conseguir que tu oferta sea el nombre de una categoría nueva — y pasar de competir contra otras agencias a competir contra la ausencia del resultado.

Cuando consigues eso, dejas de existir en los comparadores de la vieja categoría. Y los clientes que nadie más ha educado empiezan a llamar a tu puerta con una pregunta que ya no es "¿qué incluye y cuánto cuesta?".

Es "¿puedo permitirme no tener esto?".

Llevo cuatro años viendo operadores pequeños hacer exactamente lo contrario de lo que dicta el instinto. Los que escalan no son los que mejor empaquetan su servicio. Son los que se atreven a declarar que su oferta resuelve un problema que una categoría entera ha ignorado. El empaquetado es cómodo. La categoría da vértigo. Y el vértigo, en este negocio, es la señal de que vas por el buen camino.

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

Abre tu dashboard de SendGrid. Mira cualquiera de tus templates activos.

*No puedes mover esa plantilla a Mailgun sin reescribirla desde cero.*

No es culpa tuya. Es el modelo de negocio. SendGrid, Mailgun, SES — todos os atan a su formato de plantillas porque la retención es más rentable que la calidad. Los proveedores legacy no compiten en entregabilidad — la entregabilidad es un commodity desde 2023 si configuras SPF, DKIM y DMARC bien. Compiten en lock-in.

Resend rompe ese juego. No te vende plantillas propietarias: te vende código. Componentes de React Email que viven en tu repositorio, se versionan con Git y se despliegan con tu app. Cuando tu proveedor sube el precio o te falla un rate limit, te llevas tus plantillas contigo y cambias de API en un finde.

Este es el tutorial que me hubiera gustado tener cuando monté el sistema de email de conversoriaecnae.es — y el que aplico en cada proyecto nuevo que uso Resend.

Por Qué Todos los Proveedores Entregan Igual (y Cómo Lo Compruebas)

Aquí va la verdad incómoda del sector: *la entregabilidad ya no es un diferenciador entre proveedores de email transaccional. *

¿Por qué? Porque la entregabilidad depende de tres cosas que controlas tú, no el proveedor:

1. SPF — qué servidores están autorizados a enviar por tu dominio.

2. DKIM — la firma criptográfica que verifica que nadie ha tocado el correo.

3. DMARC — la política que dice a Gmail y Outlook qué hacer si fallan las dos anteriores.

Configúralas bien y desde cualquier proveedor serio llegas al 99% de entregabilidad en correos transaccionales. Configúralas mal y ni el mejor proveedor del mundo salva tu dominio.

Gmail y Outlook ya exigen DMARC desde 2024 para remitentes masivos. La barrera de entrada subió, y eso aplana el campo de juego: los que sobreviven tienen la infraestructura igualada.

Entonces, ¿por qué Resend importa si SES cuesta menos?

Porque el coste real del email no es el envío. Es el desarrollo.

El Problema Real: SES Te Cobra el Envío y Te Hace Pagar el Desarrollo

Os propongo un experimento mental. Monta un email transaccional con AWS SES y uno con Resend.

Con SES necesitas:

• La SDK de AWS en tu proyecto (o firmar peticiones manualmente con SigV4).

• Un sistema de template propio o te encajas con el formato de SES.

• Configurar el feedback loop manualmente.

• Debuggear un cuerpo de petición que parece escrito por alguien que odia a los desarrolladores.

❌ Esto es lo que pasa con SES: pasas 3 horas intentando entender el SDK, otra hora peleando con el formato de template, y acabas con un sistema que solo funciona en tu máquina.

Con Resend:

```typescript

// Tu pipeline de email completo en ~40 líneas

import { Resend } from 'resend';

const resend = new Resend(process.env.RESEND_API_KEY);

// La plantilla es un componente React. Vive en tu repo.

import { WelcomeEmail } from '@/emails/WelcomeEmail';

await resend.emails.send({

from: 'Acme <onboarding@tu-dominio.com>',

to: ['usuario@ejemplo.com'],

subject: 'Bienvenido a Acme',

react: <WelcomeEmail username="carlos" />,

});

```

✅ Lo que tienes con Resend: un endpoint en TypeScript, la plantilla como componente tipado con props, y el envío en una línea.

SES vende infraestructura. Resend vende experiencia de desarrollo. La primera te cuesta horas. La segunda te las devuelve.

El Modelo de 3 Capas para No Morir en el Intento

Me preguntáis siempre lo mismo: "¿Cómo montas el email en producción sin volverte loco?".

La respuesta es el modelo que llamo el Modelo de 3 Capas para No Morir en el Intento. Tres capas separadas que no se mezclan:

Capa 1: React Email — Las Plantillas como Código

Tu primer error es tratar las plantillas como artefactos del proveedor. Resend elimina ese error de raíz: usa React Email, que compila componentes JSX a HTML compatible con los 8 clientes de correo principales.

```tsx

// emails/WelcomeEmail.tsx — una plantilla portable

import { Html, Body, Container, Heading, Text, Button } from '@react-email/components';

export function WelcomeEmail({ username }: { username: string }) {

return (

<Html>

<Body style={{ fontFamily: 'Arial, sans-serif', padding: '20px' }}>

<Container>

<Heading>¡Bienvenido, {username}!</Heading>

<Text>Gracias por registrarte en tu-dominio.com.</Text>

<Button href="https://tu-dominio.com/dashboard" style={{ background: '#22c55e', padding: '12px 24px' }}>

Ir al dashboard

</Button>

</Container>

</Body>

</Html>

);

}

```

Esa plantilla es un fichero más de tu repo. Haces commit, code review, tests con Vitest y despliegas. Si mañana migras de Resend a otro proveedor, los componentes se quedan — solo cambia la capa de envío.

Otra cosa que me encanta: la librería de preview de React Email. Recibes el correo renderizado en tu navegador sin mandar un solo email real. Delegas el diseño al desarrollador, no al marketer que edita templates en un drag & drop roto.

Capa 2: La API — Un Endpoint en tu Edge Function, no un Servicio Aparte

Resend se integra de forma nativa con Vercel Edge Functions y Next.js Route Handlers. Eso significa que tu lógica de email vive en el mismo runtime que tu app.

```typescript

// app/api/send-welcome/route.ts — Next.js App Router

import { Resend } from 'resend';

import { WelcomeEmail } from '@/emails/WelcomeEmail';

const resend = new Resend(process.env.RESEND_API_KEY);

export async function POST(request: Request) {

const { email, username } = await request.json();

// Validas con Zod, no con un if gigante

const { data, error } = await resend.emails.send({

from: 'Tu App <hola@tu-dominio.com>',

to: [email],

subject: 'Bienvenido a Tu App',

react: WelcomeEmail({ username }),

});

if (error) {

return Response.json({ error }, { status: 400 });

}

return Response.json({ id: data?.id }, { status: 201 });

}

```

Capa 3: Los Webhooks — Donde Se Gana la Batalla de la Reputación

Todo el mundo configura el envío. Casi nadie configura el feedback loop. Ese es el error que te hunde el dominio a los tres meses de escalar.

Resend manda webhooks por cada evento: `email.sent`, `email.delivered`, `email.opened`, `email.clicked`, y el más importante de todos — `email.bounced` y `email.complained`.

Un correo que rebota no es un problema puntual: es un martillazo a tu reputación de dominio. Si no lo purgas de tu base de datos en minutos, el siguiente envío masivo perjudica a todos los demás.

Montar el webhook es directo:

```typescript

// app/api/webhooks/resend/route.ts

import { NextResponse } from 'next/server';

export async function POST(request: Request) {

const body = await request.json();

// Eventos: email.bounced, email.complained, email.delivered

if (body.type === 'email.bounced') {

await updateUserStatus(body.data.email, 'bounced');

// Lógica de purga del usuario de tu base de datos

}

if (body.type === 'email.complained') {

// Marcar como spam — bloquea TODOS los envíos futuros a ese contacto

await blockContact(body.data.email);

}

return NextResponse.json({ ok: true });

}

```

Con este webhook activo, la purga de rebotes es automática. Tu reputación de dominio se mantiene intacta mientras escalas. Es la diferencia entre tener 100 contactos sucios y que Gmail te meta en spam, o purgarlos en tiempo real y mantener entregas limpias al 99%.

El Patrón que Falló en Producción: Lo Que No Debes Hacer

Vale, os he dado el camino correcto. Ahora el atajo que os va a morder el culo.

❌ Patrón roto: enviar emails desde el request principal.

```javascript

// ❌ NUNCA hagas esto

app.post('/registro', async (req, res) => {

await db.createUser(req.body);

await resend.emails.send({ ... }); // Bloquea la respuesta 400ms

res.json({ ok: true });

});

```

Cuatrocientos milisegundos de bloqueo por cada registro. Con 10 registros concurrentes, tu API ya huele a humo.

✅ Patrón correcto: desacopla el envío.

```typescript

// ✅ La respuesta vuelve al instante. El email viaja en cola.

app.post('/registro', async (req, res) => {

await db.createUser(req.body);

await notificationsQueue.publish('welcome-email', req.body.email);

res.json({ ok: true }); // ~50ms, no 400ms

});

```

El email transaccional no es transaccional en el sentido estricto: es asíncrono. Trátalo como tal y tu API escala. Trátalo como parte del request y tu backend muere con tu primer pico de tráfico.

Resend Te Da la Salud del Pipeline, no Solo el Envío

El dashboard de Resend no es un radiador de números bonitos. Es diagnóstico clínico.

Cada envío te da un rate limit claro y configurable por dominio o por campaña. Te muestra health score por dominio, streaks de entregabilidad y advertencias tempranas cuando tu reputación empieza a degradarse.

Eso es lo que ningún proveedor legacy te da por defecto: visibilidad operativa sin tener que montar un pipeline de observabilidad paralelo. Con SES necesitas CloudWatch, presupuestos personalizados y un ingeniero a media jornada solo para entender qué está pasando.

En Resend, el feedback loop está integrado en la experiencia. Los webhooks llegan a un endpoint que montas en veinte minutos, y el dashboard te cuenta la historia antes de que se convierta en un incidente.

La Migración no Duele si Tu Plantillas Viven en Tu Repo

Vamos directos a la conclusión incómoda: si uses el proveedor que uses, *tus plantillas deben vivir en tu repositorio, no en el dashboard del proveedor.*

React Email no es exclusivo de Resend. Puedes usar los componentes con cualquier proveedor que acepte HTML — que son todos. La diferencia es que Resend lo hace trivial: pásale el componente directamente como prop `react` y se encarga de compilarlo por ti.

Mi recomendación práctica:

1. Empieza con React Email en cualquier proyecto nuevo. Todas las plantillas como componentes en una carpeta `emails/`.

2. Usa Resend como proveedor por defecto — no por la entregabilidad, sino porque el DX te ahorra semanas de fricción con SDKs y formatos propietarios.

3. Monta los webhooks el día uno, no cuando ya has perdido la reputación de tu dominio.

4. Desacopla el envío del request con una cola o un job. El email es asíncrono, no importa lo que diga tu intuición de backend.

El email no es sexy. Es la columna vertebral de cualquier producto SaaS — y la mayoría de equipos lo monta como si fuera una ocurrencia de última hora.

Resend te da el marco para montarlo bien desde el principio. La entregabilidad es un commodity que se configura una vez y se olvida.

*El developer experience es el único moat que importa — porque el tiempo de tu equipo es el único coste que el proveedor no puede bajar por ti.*

Cada hora que no peleas con un SDK o un template propietario es una hora que dedicas a tu producto. Ese es el verdadero retorno de Resend. Y en 2026, con marcos como Next.js empujando todo hacia frameworks opinados, la apuesta por un proveedor que se alinea con tu stack — en vez de imponerte el suyo — es la única que no te va a dejar atrapado en 2030.

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 pivotar un servicio productizado es un acto de valentía. Que cuando los clientes se van, el equipo se aburre o el margen aprieta, la respuesta audaz es cambiar de producto, resetear expectativas y empezar de nuevo con la emoción del reinicio.

*Te has equivocado de diagnóstico.*

El 90% de los pivots en servicios productizados no son una respuesta al mercado. Son un acto de cobardía estratégica — un nombre bonito para una huida hacia adelante. Y la señal más peligrosa no es la que te grita "cambia de producto". Es la que te susurra que el aburrimiento de ejecutar lo mismo es un diagnóstico, cuando en realidad es el precio de haber ganado.

Llevo cuatro años enviando software en España. He montado gestorías conectadas, productos para servicios jurídicos, módulos para IRPF. Y he visto docenas de operadores —agencias digitales, freelancers, consultores técnicos— tirar a la basura ventaja acumulada de años de entrega repetible, proceso depurado y posicionamiento ganado, solo porque confundieron su impaciencia con una señal del mercado.

El coraje real no está en cambiar de producto. Está en aguantar el aburrimiento de la ejecución repetible y diagnosticar si el dolor que sientes viene del mercado o de tu propia ansiedad.

---

El pivot como fuga hacia adelante: por qué es tan atractivo

Profundizar en un servicio productizado es trabajo de capitalización aburrido. Significa repetir, medir, refinar, documentar, sistematizar. No da titulares. No genera dopamina. Es exactamente el tipo de trabajo que nadie celebra.

Pivotar, en cambio, es el atajo gratificante: novedad, reset de expectativas, la ilusión de progreso. Psicológicamente, el pivot es la opción gratificante a corto plazo y estratégicamente ruinosa a largo plazo.

La asimetría es brutal. Pivotar regala la ventaja acumulada de años de entrega repetible —el proceso depurado, el posicionamiento ganado, el conocimiento del ICP— a cambio de la emoción de un reinicio. Es como un atleta que cambia de deporte cada temporada porque entrenar lo mismo todos los días le aburre. Nunca llega a ser competitivo en nada.

❌ Lo que el 90% hace: Nota dolor → Interpreta como señal de mercado → Pivota rápido para sentirse valiente.

✅ Lo que el 10% legítimo hace: Nota dolor → Etiqueta el síntoma con una taxonomía → Aplica test de amplitud → Revisa posicionamiento → Prueba profundización → Solo entonces decide.

---

La taxonomía del ruido operativo: aprende a etiquetar tu síntoma

Antes de decidir nada, necesitas saber qué estás sintiendo. El ruido operativo en servicios productizados tiene una taxonomía reconocible, y casi todo lo que los operadores llaman "señal de mercado" cae en una de estas cuatro casillas:

1. Churn de un puñado de clientes. Perder dos o tres clientes en un mes te duele. No te dice nada sobre el mercado. Los clientes se van por decenas de razones que no tienen que ver con tu producto: presupuesto interno, cambio de prioridades, un decisor nuevo. Perder dos clientes no es señal. Es estadística.

2. Fatiga de entregables. "Estoy harto de entregar lo mismo cada mes". Traducción real: has automatizado mal, no has delegado, o no has subido de nivel a tus clientes. La fatiga no prueba que el producto haya tocado techo. Prueba que tu modelo de entrega tiene un agujero — y el agujero se tapa, no se esquiva.

3. Presión de margen por alcance mal controlado. Si tu margen aprieta porque un cliente te ha ido comiendo alcance sin pagar más, el problema no es el producto. Es tu control de scope. Pivotar no te salva de un cliente que no sabes gestionar: el siguiente te hará lo mismo.

4. Aburrimiento del equipo. El argumento favorito: "si el equipo está aburrido de entregar lo mismo, la calidad se resiente". Falso en el 90% de los casos. El aburrimiento suele ser un problema de delegación, staffing o variedad de retos dentro del mismo producto — subir de nivel a clientes, ampliar entregables, automatizar lo repetible. Confundir aburrimiento con límite del producto es precisamente el error que el 90% comete.

Ninguno de estos cuatro síntomas es evidencia de que el mercado quiera otro producto. Son síntomas del modelo de entrega: ICP equivocado, sin control de scope, delegación insuficiente.

---

La conexión subversiva: tu posición está rota, no tu producto

Aquí está el punto más incómodo. Muchos "momentos de pivot" son en realidad el resultado de años de posicionamiento vago o sobregeneralizado.

El síntoma clásico: ganas clientes que te compran una cosa pero creen que les vendes otra. El proyecto llega, las expectativas no cuadran, el cliente se frustra, tú te frustras, y en tres meses estás convencido de que "este producto no funciona".

*No es el producto. Es tu posición.*

Si tu oferta es lo suficientemente difusa como para atraer a clientes que te compran por una razón equivocada, el problema nunca fue el delivery. Fue que aceptaste el cliente equivocado porque tu posicionamiento no filtraba.

La corrección no está en pivotar. Está en estrechar, aclarar o reposicionar la oferta. Escribir un posicionamiento más específico, definido el ICP con más precisión, y dejar que la oferta rechace a los clientes equivocados antes de que te compren.

Es la jugada barata que nadie quiere hacer. Porque reposicionar no da titulares, no genera la emoción de "empezar algo nuevo". Pero suele disolver la falsa señal sin necesidad de tocar el producto.

---

El Framework de las 5 Paradas: cómo decidir si toca pivotar

Aquí tienes el mecanismo. Cinco paradas obligatorias antes de permitirte pronuncar la palabra pivot. Si superas las cinco con una señal intacta, tienes derecho al 10% legítimo. Si mueres en cualquiera de ellas, tu pivot era impulsivo.

Parada 1 — Nombra el gatillo emocional antes de tocar datos.

Escribe, en un fichero, qué emoción inició el impulso de pivotar. ¿Aburrimiento? ¿Frustración con un cliente concreto? ¿Miedo a quedarte obsoleto? ¿Comparación con un competidor?

Si el disparador es puramente emocional —y te sorprenderá cuántas veces lo es—, el pivot ya parte con sospecha de ser falso. Estás tratando una emoción con una decisión estratégica, y eso nunca funciona.

Parada 2 — Aplica la prueba del ruido (amplitude test).

¿La señal aparece en todos tus clientes, verticales y tipologías de proyecto, o está concentrada en uno o dos casos concretos?

Regla clara: señal concentrada = ruido operativo. Es un cliente equivocado, un alcance mal gestionado, un segmento concreto que nunca debiste aceptar. Señal sistémica = candidata a estratégica. Si el dolor se reproduce en múltiples segmentos de tu cartera, sostenido en el tiempo, empieza a ser interesante.

Parada 3 — Relee tu posicionamiento antes de tocar el producto.

Si ganas clientes que te compran una cosa y entregas otra, o viceversa, el problema es de posicionamiento, no de producto. Reescribir el posicionamiento —con un ICP más estrecho, una promesa más concreta, un filtro más agresivo— suele disolver la señal falsa sin pivotar.

No toques una línea de tu oferta hasta que hayas reposicionado y dado tiempo a que el nuevo filtro cambie la calidad de las oportunidades entrantes.

Parada 4 — El test de profundización.

Pregúntate si la solución al dolor es añadir profundidad a la oferta actual en lugar de crear una oferta nueva. Profundidad significa: un nuevo entregable, un nuevo segmento del mismo ICP, una nueva fase del journey del cliente, un nivel de servicio superior.

Si existe una respuesta de profundidad creíble, el pivot no toca. Solo tienes que ejecutar la profundización.

Parada 5 — Periodo de enfriamiento + hipótesis explícita.

Aplaza la decisión 30 días. Y durante ese periodo, escribe la hipótesis falsable que confirmaría el pivot:

> "Si en ocho semanas el churn del segmento Y supera el umbral Z sin causa externa identificable, pivotamos."

Escribe la hipótesis con métricas concretas. Luego espera. La mayoría de los impulsos de pivot no sobreviven a su propia hipótesis escrita. Cuando el impulso era emocional, la hipótesis se revela como lo que es: una justificación buscando datos.

---

Respondiendo a tus objeciones — porque ya sé lo que estás pensando

"Mi pivot me salvó el negocio — ¿dices que todos los pivots son malos?"

No. El 90% no es el 100%. El 10% legítimo existe: señal sistémica, sostenida en el tiempo, con hipótesis falsable y causa exógena verificable. Este framework no existe para prohibir pivotar. Existe para hacerte ganar el derecho a hacerlo, demostrando que no estás huyendo.

"El churn y la caída de negocio SÍ son señal estratégica."

Válido, pero exige umbrales. Una caída sostenida en múltiples segmentos, con causa exógena verificable —cambio regulatorio, desaparición de un canal, un competidor que entró con otra estructura de precios— es estratégica. Perder dos clientes en un mes, o un segmento concreto mal gestionado, es ruido. La distinción no es arbitraria: se mide en amplitud y duración.

"Si el equipo está aburrido, eso es señal real: el aburrimiento mata la calidad."

El aburrimiento mata la calidad solo cuando el operador confunde el síntoma con la causa. Un equipo aburrido es un problema de retos, delegación y automatización resoluble dentro del mismo producto. Que un equipo se aburra no prueba que el mercado se haya aburrido también. Esa es la confusión más cara de todo el ecosistema.

---

La honestidad metodológica que este artículo te debe

Un apunte necesario: el "90%" que da título a este artículo no es una estadística de un estudio publicado. Es una cifra estimativa con valor diagnóstico, construida sobre la experiencia de operadores del sector. Úsala como lo que es: un heurístico para inclinar la presunción en contra del pivot. No como un dato medido que puedas citar en una reunión de inversores. La honestidad es parte del oficio — y el propio hecho de que el sector fabrique métricas falsas para justificar pivots es precisamente el vicio que este framework combate.

---

Lo que esto significa para ti, hoy

Si has llegado hasta aquí con el impulso de pivotar activo, tu siguiente paso no es decidir. Es aplicar las cinco paradas. Nombrar la emoción. Medir la amplitud. Releer tu posicionamiento. Buscar la opción de profundidad. Escribir tu hipótesis falsable y esperar 30 días.

Probablemente descubrirás lo que el 90% descubre demasiado tarde: el problema no era tu producto. Era tu negativa a profundizar en él. Y la ventaja que estabas a punto de regalar es exactamente la que el operador paciente va a capitalizar.

El pivot no es la respuesta valiente. Es la salida fácil disfrazada de coraje. El coraje real está en sentarte, aguantar el aburrimiento de capitalizar lo que ya construiste, y preguntarte la única pregunta que importa: ¿qué profundidad le falta a esto que ya funciona?

Cuando respondas esa pregunta, no necesitarás pivotar. Necesitarás excavar.

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

Un core, dos vistas: KYB para bancos y onboarding para SaaS sin duplicar lógica

El mismo dato, dos respuestas distintas

Cuando una empresa se da de alta, hay una única pregunta de fondo que arrastra a todas las demás: qué hace exactamente esa actividad y qué obligaciones fiscales genera. Lo que descubrí construyendo Conversor es que esa pregunta tiene al menos dos interlocutores que no se hablan entre sí y que esperan respuestas con formas completamente distintas.

Por un lado, un banco regional español. Cuando abre una cuenta a una empresa necesita hacer su verificación de negocio, lo que se llama KYB. No le interesa qué modelos tiene que presentar el autónomo en mayo. Quiere saber en qué sector de riesgo cae la actividad, de dónde salió ese dato y si la entidad reside en la UE.

Por el otro, un SaaS fiscal. Ese sí quiere exactamente lo otro: qué declaración de alta le toca, qué pasa con el IVA y la retención, qué régimen le conviene, el calendario de obligaciones y la cuota RETA.

Son dos respuestas que casi no comparten un solo campo. Y sin embargo salen de la misma operación de fondo: resolver una actividad económica en un perfil fiscal completo.

Mi primer impulso: dos endpoints, dos lógicas

Lo razonable, cuando dos clientes tan distintos te piden cosas tan distintas, es construirlo dos veces. Un endpoint para el banco, otro para el SaaS, cada uno con su propio código. Al fin y al cabo las respuestas no se parecen en nada: qué sentido tiene unificar lo que no comparte estructura.

Me parecía la decisión honesta. Si el banco necesita un sector de riesgo y un audit de fuentes, y el SaaS necesita la declaración de alta y un calendario, montar una capa común era forzar una abstracción antes de tiempo. Y las abstracciones prematuras son el clásico error que uno comete por no querer escribir dos veces la misma línea.

Así que empecé a escribir los dos endpoints por separado. Y fue entonces cuando apareció el error que me obligó a replantearlo todo.

El error: helpers en route.ts y un build que tsc no vio

Por comodidad, metí los helpers de proyección directamente en el fichero de la ruta, `route.ts`, y los exporté desde ahí. Quería reutilizar una función de mapeo en el otro endpoint o en un test, y me parecía lo natural: están en el mismo fichero, por qué no exportarlas.

El chequeo de tipos no dijo nada. `tsc` pasaba limpio. Todo compilaba en local. Y aun así, el build de Vercel se rompió.

La razón es una de esas restricciones de framework que no están en el compilador: Next.js App Router rechaza los exports que no son de Route en `route.ts`. El fichero de una ruta solo puede exportar lo que el router espera. Si exportas cualquier otra cosa, el build falla aunque TypeScript esté satisfecho.

Fue un error que me costó un buen rato localizar porque la señal venía del sitio equivocado. El compilador decía "bien", el deploy decía "no". Y el mensaje de error no apuntaba a mi función: apuntaba a una regla de convención que yo no conocía.

La solución: un core, dos vistas

La corrección me enseñó dos cosas a la vez, y las dos apuntaban al mismo sitio: `lib/`.

Primero, los helpers de proyección tienen que vivir en `lib/`, nunca exportarse desde `route.ts`. Es la regla que ahora respeto sin discutir. En `lib/api/activity-profile.ts` está el core: `resolveActivity` resuelve la actividad y `assembleDossier` monta el perfil fiscal completo.

Segundo, y esto es lo importante: una vez que el core vive fuera de las rutas, las dos vistas dejan de ser dos lógicas duplicadas y pasan a ser dos proyecciones delgadas sobre el mismo núcleo.

`/api/v1/kyb/enrich` es la vista del banco: devuelve `fiscal_profile.sector_riesgo` y lo acompaña de un audit con las fuentes, el `data_version` y la residencia UE. El banco no tiene que confiar en un número suelto; tiene de dónde salió y cuándo se generó.

`/api/v1/onboarding/activity` es la vista del SaaS: devuelve el `alta_036`, el IVA y la retención, el régimen recomendado, el calendario y la RETA. Es la respuesta que un producto de gestión necesita para arrancar el alta sin montar su propia capa de datos fiscales.

Las dos respuestas siguen sin parecerse en casi nada. Pero ahora comparten un único punto donde se resuelve la verdad fiscal. Si un día tengo que cambiar cómo se mapea un epígrafe del IAE, lo cambio una vez, en el core, y las dos vistas se corrigen solas.

Lo que aprendí

La lección no es "no dupliques código", que es un consejo barato. Es más concreta. La duplicación aquí no era solo un coste de mantenimiento: era un coste de corrección. Dos copias de "actividad a perfil fiscal" acaban divergiendo, y el día que divergen, el banco y el SaaS te devuelven respuestas distintas para la misma actividad. Eso no es un refactor pendiente, es un dato fiscal que deja de ser fiable.

Y la segunda lección: el compilador no es el único contrato que hay que respetar. Next.js tenía una regla de convención que TypeScript no podía ver, y me la explicó a base de romper el deploy. Desde entonces trato las restricciones del framework como parte del tipo: no basta con que `tsc` pase, el fichero de una ruta tiene su propio contrato de qué puede exportar.

El core resuelve una vez, las vistas proyectan y los helpers viven en `lib/`. Eso es todo, y me costó un build roto aprenderlo.

Si quieres ver los dos endpoints en detalle, los docs están abiertos: https://www.conversoriaecnae.es/api/v1/docs

Cada vez que escucho "Supabase es el Firebase de Postgres", muero un poco.

Es la comparación al revés. La dirección real es la inversa: MySQL reinó en la web de los 2000, y luego Firebase convenció a una generación de que los documentos NoSQL eran el futuro. Pero PostgreSQL —ese motor "aburrido" de 35 años— ha absorbido en silencio todo lo que Firebase hacía especial: auth, realtime, storage, incluso búsqueda vectorial para IA.

Y la prueba no está en el marketing de Supabase.

Está en que si quitas PostgreSQL de debajo de cualquier feature "estrella" de Supabase, no queda nada. Quitas Postgres y no hay auth. No hay realtime. No hay vector search. El ceño fruncido de la comparación se apoya entero en una columna vertebral que es SQL puro y portable.

*El riesgo que cargas con Supabase no es el lock-in. Es lo contrario: que todo tu miedo va dirigido en la dirección equivocada. *

Empecemos por lo que la mayoría entiende mal.

El Argumento Convencional es una Falsa Dicotomía

El debate típico en 2026 se plantea así:

❌ "¿Quieres velocidad para el MVP? Usa Firebase o Supabase. ¿Quieres un backend serio para producción? Monta algo propio."

❌ "Supabase vale para hackathons. Nadie ejecuta producción sobre ella."

Ambos bandos fallan igual. Los dos tratan Supabase como un atajo del que te gradúas. Los dos ignoran que la premisa es exactamente la inversa.

✅ Supabase no es la opción fácil de la que te vas. Es el argumento de que PostgreSQL es el sitio de mayor apalancamiento para poner auth, realtime y lógica de IA.

Vamos a desmontarlo con evidencia, no con opiniones.

La Arquitectura Revela Dónde Está el Valor Real

Mira qué pasa bajo el capó cuando usas Supabase:

• Auth (GoTrue) emite JWTs. Pero la *autorización no vive en un middleware. Vive en políticas de Row-Level Security* escritas en SQL directamente en la base de datos.

• Realtime no es un websocket con un event-bus casero por encima. Se construye sobre logical replication de Postgres. Un mensaje de chat es literalmente una fila commiteada.

• AI/vector search no requiere una base de datos vectorial aparte. Es una extensión (pgvector) y una columna con una query de similitud coseno escrita en SQL plano.

• Storage, Edge Functions (Deno), PostgREST... todos son wrappers finos alrededor de Postgres y un stack open source bajo licencia Apache 2.0.

Cada feature de Supabase que te parece "magia" es una primitiva de Postgres con gabardina.

Eso tiene consecuencias que casi nadie comenta.

La Seguridad la Decide la Base de Datos, No tu API

Vengo de años escribiendo middlewares en Node/Express. Mi primer impulso fue proteger la base de datos desde la API. Supabase te obliga a un reset mental: *no estás protegiendo la base de datos de la API. La base de datos se protege a sí misma*.

Mira una política de RLS típica:

```sql

-- Creas una tabla de perfiles cuyo dueño es el usuario autenticado

CREATE TABLE profiles (

id UUID PRIMARY KEY REFERENCES auth.users(id) ON DELETE CASCADE,

username TEXT UNIQUE NOT NULL,

avatar_url TEXT

);

-- Activas RLS ANTES de escribir tu primera línea de app code

ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;

El `auth.uid()` lo sustituye Postgres por el ID del JWT que firmó GoTrue. Esas políticas se ejecutan tanto si el cliente es tu web, tu app móvil o una conexión directa de psql a la base. Un solo sitio decide seguridad, y se aplica uniformemente en cada superficie.

Esta es la demo de un signup con auth y un trigger que crea la fila de perfil automáticamente, para que identidad y datos de usuario jamás deriven:

```sql

-- Trigger que crea el perfil al registrarse

CREATE OR REPLACE FUNCTION public.handle_new_user()

RETURNS TRIGGER AS $$

BEGIN

INSERT INTO public.profiles (id, username)

VALUES (new.id, split_part(new.email, '@', 1));

RETURN new;

END;

$$ LANGUAGE plpgsql SECURITY DEFINER;

CREATE TRIGGER on_auth_user_created

AFTER INSERT ON auth.users

FOR EACH ROW EXECUTE FUNCTION public.handle_new_user();

```

El "modelo de seguridad" de tu app es SQL que vive en una migración versionada. No es middleware que puedas esquivar con una petición directa a la base.

Realtime es la Prueba de fuego de que Entiendes la Plataforma

El realtime de Supabase te enseña más de Postgres que cualquier tutorial.

Se construye sobre logical replication y cambios en el WAL. Cuando ves un mensaje nuevo en tu chat, no es un evento de un broker independiente: es una fila que Postgres commiteó. Eso tiene dos consecuencias prácticas.

Una, buena: los eventos realtime son transaccionales. No recibes eventos de datos que no llegaron a commitearse. Es más robusto que una capa casera de WebSocket + event-bus donde un mensaje puede perderse entre el write y el publish.

```js

// Suscripción a cambios reales de la base, no a un mensajero artificial

const channel = supabase

.channel('todos-changes')

.on('postgres_changes', {

event: 'INSERT',

schema: 'public',

table: 'todos'

}, (payload) => {

console.log('Fila commiteada:', payload.new);

})

.subscribe();

```

Dos, la que casi nadie discute: pagas por cada write que replicas. Una suscripción ingenua sobre una tabla caliente multiplica la carga en el WAL y en los canales de replica. El gotcha clásico de escalado es ver que el realtime "va lento" y no entender que *tu query INSERT* es el cuello de botella. Suscríbete solo a las tablas y eventos que la interfaz necesita. Nada más.

El SDK es un Cliente Fino sobre Semántica SQL — y Eso es tu Mejor Amigo (o tu Peor Pesadilla)

Aquí está la comparación que casi ningún análisis superficial hace.

Firebase te obliga a adoptar su modelo de documentos NoSQL desde el día uno. Su SDK es el modelo mental. Nunca escribes una query SQL. Nunca haces un JOIN. Supabase es lo contrario: su SDK es un cliente fino que envuelve una API REST (PostgREST) que a su vez traduce a SQL. Y puedes verlo:

```js

// supabase-js: operación CRUD

const { data, error } = await supabase

.from('todos')

.insert({ task: 'Aprender RLS', user_id: userId })

.select();

// Lo que ocurre por debajo: una petición REST a PostgREST

// POST /rest/v1/todos

// Body: { "task": "Aprender RLS", "user_id": "..." }

// Headers: { "Content-Type": "application/json", "Authorization": "Bearer <JWT>" }

```

Demistifica la "magia": un `.insert().select()` es una petición HTTP a un endpoint auto-generado que aplica tus políticas RLS antes de tocar una fila.

El SDK de Supabase es una capa fina sobre semántica SQL. Eso lo convierte en la elección perfecta si ya piensas en términos relacionales, y en la peor elección posible si nunca quieres escribir una cláusula WHERE. Un artículo honesto tiene que decirlo: el marco de "Firebase killer" halaga a Supabase mientras oculta sus trade-offs ergonómicos reales.

pgvector Colapsa Toda una Clase de Decisiones de "Infraestructura IA"

Para productos en fase temprana, pgvector elimina la necesidad de una base de datos vectorial aparte.

Añades una extensión, una columna, y lanzas una query de similitud con JOINs SQL normales hacia tus filas relacionales:

```sql

-- Activas la extensión y creas la columna de embeddings

CREATE EXTENSION IF NOT EXISTS vector;

ALTER TABLE documents ADD COLUMN embedding vector(1536);

-- Búsqueda híbrida: los documentos más cercanos de este usuario, en este workspace

SELECT d.id, d.title,

d.embedding <=> $1 AS distancia

FROM documents d

JOIN workspaces w ON w.id = d.workspace_id

WHERE d.owner_id = auth.uid()

ORDER BY d.embedding <=> $1

LIMIT 10;

```

El gancho práctico: queries híbridas tipo "los documentos más cercanos de este usuario, filtrados por su workspace" son dolorosas entre dos sistemas distintos y triviales dentro de Postgres.

Pero anota el matiz: a muy gran escala, los motores vectoriales dedicados tienen perfiles de rendimiento distintos. Esto es una simplificación arquitectónica, no una verdad universal. Para tu producto en fase temprana, es la decisión correcta.

Para mover la generación de embeddings fuera del navegador, sácala a una Edge Function de Deno:

```ts

// Edge Function (Deno): genera y guarda el embedding sin exponer secretos

Deno.serve(async (req) => {

const { content, docId } = await req.json();

const res = await fetch("https://api.openai.com/v1/embeddings", {

method: "POST",

headers: {

"Content-Type": "application/json",

"Authorization": `Bearer ${Deno.env.get("OPENAI_API_KEY")}`,

},

body: JSON.stringify({ model: "text-embedding-3-small", input: content }),

});

const { data } = await res.json();

await supabase.from("documents")

.update({ embedding: data[0].embedding })

.eq("id", docId);

return new Response("ok", { status: 200 });

});

```

Secretos y compute pesado nunca llegan al navegador. Es Postgres puro por debajo.

El Framework que Propongo: El Patrón Schema-First con RLS como Fuente de Verdad

Aquí está el método que aplico en cada build que hago con Supabase. Lo llamo El Patrón Schema-First con RLS como Fuente de Verdad, y funciona así:

Paso 1 — Diseña el esquema en SQL puro ANTES de tocar tu app code.

Tablas, constraints, índices, claves foráneas. La carpeta de migraciones es la fuente de verdad. Cada feature de Supabase cuelga de la base de datos, así que si el esquema está mal, todo lo demás se arrastra mal.

Paso 2 — Activa ROW LEVEL SECURITY en cada tabla y escribe políticas explícitas con `USING` y `WITH CHECK`.

Referencia `auth.uid()` directamente. Verifica con un rol que no sea el owner antes de construir cualquier interfaz. Si no puedes leer tu propia fila con un rol distinto al dueño, no toques una sola línea de React.

Paso 3 — Conecta Auth al esquema con triggers.

Crea la fila de profile en el signup (como en el snippet de arriba) para que identidad y datos de usuario jamás deriven. Nunca sincronices a mano desde el cliente.

Paso 4 — Adopta realtime de forma selectiva.

Suscríbete solo a las tablas y eventos que la UI necesita. Apóyate en los change data de Postgres, no en polling del cliente. Recuerda: cada replicación cuesta, así que no repliques tablas calientes por costumbre.

Paso 5 — Para features de IA, empieza con una columna pgvector.

Guarda los embeddings junto a las filas fuente. Mueve la generación de embeddings a una Edge Function (Deno) para que los secretos y el compute pesado jamás lleguen al navegador.

El Lock-In no Existe. Pero las Respuestas Honestas a tus Objeciones Sí

Vamos con las tres objeciones que sé que estáis pensando.

"Supabase vale para un hackathon, pero nadie ejecuta producción sobre ella."

El core es PostgreSQL gestionado con tooling estándar — pg_dump, psql, migraciones versionadas. El stack open source (Postgres, GoTrue, Realtime, Storage, PostgREST, Edge Functions) es autohospedable y se usa en producción. Lo que sí debes dimensionar honestamente son los techos operativos del servicio gestionado: límites de conexiones, multi-región y fan-out de realtime muy grande. Ahí, tu opción de salida ya está definida desde el día cero.

"RLS es listo, pero mi equipo no piensa en SQL, y acoplar auth a políticas de base de datos es rígido."

La curva de aprendizaje es real. Pero existe un workflow de depuración: ejecuta tus queries como el rol autenticado y ve qué devuelve. Y las políticas pueden saltarse deliberadamente con flujos service-role para operaciones server-side. El modelo no es tan inflexible como parece a primera vista.

"Si Supabase es solo Postgres, ¿por qué no gestiono Postgres yo mismo con un backend de Node pequeño?"

Concesión total — y que sea la última jugada del artículo. El valor de Supabase no es un motor propietario: es un bundle mantenido de features de Postgres difíciles de operar (realtime, storage, auth, edge compute). La respuesta honesta es que, en el momento en que tu carga operativa supere tu velocidad de features, el exit con Postgres estándar es exactamente por qué la elección fue segura.

*Empiezas en Postgres. Supabase solo pasa a ser el wrapper mejor mantenido que existe alrededor de él. *

El Veredicto Final

La mejor llamada de Supabase no es su tecnología. Es la honestidad de su apuesta: no venderte un motor propietario bonito, sino decirte que el motor más aburrido y probado de la industria es ahora el sitio de mayor apalancamiento para tu auth, tu realtime y tu lógica de IA.

El 90% del miedo a Supabase es miedo al lock-in dirigido hacia el sitio equivocado. No estás atado a un ecosistema cerrado; estás escribiendo SQL portable sobre un motor de 35 años con una comunidad imposible de ignorar.

Cuando encuentres el techo operativo del servicio gestionado —y lo encontrarás—, tu salida es un volcado estándar, no un rewrite de diez semanas.

La pregunta en 2026 no es "¿Firebase o Supabase?".

Es "¿cuándo vais a dejar de tratar Postgres como la base de datos y empezar a tratarla como la capa de aplicación que ya es?"

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

Y tu backend bloquea durante segundos para devolverte un 200 cuando un 202 habría hecho el trabajo.

Llevamos una década optimizando APIs para que respondan temprano. El instinto contrario —tardío, perezoso, diferido— es el que de verdad escala.

*La mejor llamada a la API no es la que haces primero. Es la que haces el último. *

No hablo de una librería. Hablo de un patrón de diseño que atraviesa todo tu stack: el cliente que deja de refetchar por accidente, el backend que responde 202 en vez de bloquear, y el protocolo que formaliza la lentitud como una característica.

Y sí, en 2026 este patrón se está convirtiendo en la alternativa real a las APIs de redes sociales como X — porque cuando el feed que consumes se genera bajo demanda en servidores que no controlas, tratar cada petición como un fetch síncrono y eager es la forma más rápida de quemarte en rate limits.

El Instinto Eager es el Error por Defecto

La sabiduría convencional en ingeniería web dice: fetch temprano, preload, cachea agresivamente para esconder la latencia.

Una llamada hecha "tarde" se trata como un fallo de preparación. Como un bug de rendimiento.

Pero mirad la evidencia. TanStack Query —la librería de fetching de datos más usada en el ecosistema React— tiene un `staleTime` por defecto de 0. Eso significa que cada remount o refocus de ventana dispara un refetch completo. Tu "caché" no está cacheando: está refetcheando ligeramente menos a menudo.

Y el coste del eager es silencioso y estructural:

→ Payloads descargados, parseados y cacheados que nadie ve jamás.

→ Bugs de invalidación de caché imposibles de rastrear.

→ Acoplamiento síncrono forzado entre componentes que no comparten datos.

El fallo del eager es invisible. Un payload se descarga, se cachea, se invalida y se vuelve a descargar — y nadie se entera.

El fallo del late es un spinner. Y un spinner se ve. Y un spinner se arregla.

Esa asimetría es exactamente por qué los equipos sobre-optimizan fetches tempranos en vez de eliminarlos.

❌ El enfoque clásico: fetch de todo al montar la página "por si acaso".

✅ El enfoque Late: fetch solo cuando los datos son visibles, batched, y con staleness explícita.

Por Qué "Fecha Temprano" es un Impuesto que Pagas Sin Verlo

Mirad lo que pasa con un fetch típico de dashboard:

```jsx

// Eager — el default: fetches al montar aunque la sección no sea visible

const { data } = useQuery(['dashboard'], fetchDashboard)

// Late — fetch solo cuando la sección entra en viewport

const { data } = useQuery(

['dashboard'],

fetchDashboard,

{ enabled: isSectionVisible, staleTime: 60_000 }

)

```

Un boolean (`enabled`) más un `staleTime` convierte una llamada eager en una llamada tardía. Y el cambio de código es de dos líneas.

El patrón N+1 documentado en el ecosistema GraphQL nace exactamente de esto: resolver cada campo con su propia llamada eager produce N round-trips. La solución canónica —DataLoader, de Lee Byron y el equipo de GraphQL— existe precisamente porque aplaza cargas individuales y las fusiona en una única query batched tardía.

```javascript

// NO hagas await fetch(user.id) dentro de cada resolver

// Deja que el batch salga tarde, en una sola query

const userLoader = new DataLoader(ids => batchFetchUsers(ids))

// En el resolver:

userLoader.load(userId) // la carga real ocurre cuando el batch está lleno

```

HTTP Ya Tiene el Status Code Para esto: 202 Accepted

El protocolo HTTP define desde hace décadas un código de primera clase para resultados deliberadamente tardíos.

202 Accepted significa: "el servidor ha aceptado la petición, pero el procesamiento no ha terminado". Es la señal canónica para ejecución diferida — frente al 200 bloqueante que ignora la semántica real de la operación.

Mirad la diferencia:

```javascript

// Express — 200 bloqueante (el cliente espera segundos)

app.post('/reports', async (req, res) => {

const result = await generateReport(req.body) // bloquea

res.json(result)

})

// Express — 202 + endpoint de estado

app.post('/reports', async (req, res) => {

if (!validIdempotencyKey(req.headers['idempotency-key'])) {

return res.status(400).json({ error: 'Idempotency-Key requerida' })

}

const jobId = await queue.enqueue(req.body)

res.status(202).json({ jobId, statusUrl: `/reports/${jobId}` })

})

app.get('/reports/:id', async (req, res) => {

const job = await store.get(req.params.id)

return job.done

? res.json(job.result)

: res.status(202).json({ status: 'pending' })

})

```

El 202 no es solo un código de estado. Es un cambio de contrato: convierte al cliente de un llamador síncrono en un suscriptor de su propio trabajo. Encolas un job, devuelves un `jobId`, expones un endpoint de estado y empujas la finalización vía webhook o SSE.

El patrón funciona igual en Python con FastAPI:

```python

from fastapi import BackgroundTasks

@app.post('/reports', status_code=202)

async def create(payload: Payload, bg: BackgroundTasks):

job_id = uuid4()

bg.add_task(generate_report, job_id, payload)

return {'id': str(job_id), 'status': f'/reports/{job_id}'}

```

Los Datos Que Confirman el Giro: Late es una Alternativa Real

No estoy describiendo una teoría bonita. El giro hacia lo tardío está formalizándose en tres capas distintas del stack:

→ Protocolo: la especificación GraphQL está incorporando `@defer`/`@stream` como características nativas, no como hack. Con incremental delivery, una sola query devuelve su camino crítico rápido inmediatamente y streamea el sub-grafo lento después por la misma conexión. La dicotomía entre "todo ahora" y "todo después" colapsa en una decisión por campo:

```graphql

query Home {

hero { name }

... @defer {

recommendations { items { id } }

}

}

```

El hero pinta al instante. Las recomendaciones llegan tarde. Ambas sobre la misma conexión.

→ Clientes: los equipos que suben su `staleTime` de 0 a un valor explícito eliminan decenas de refetches accidentales sin tocar arquitectura. Es la victoria Late más barata que existe.

→ Infraestructura: SSE y gRPC server-streaming mantienen la conexión abierta y empujan resultados a medida que los chunks completan — convirtiendo una única respuesta tardía en un stream de resultados parciales.

El Contrapeso: Cuándo Ser Tardío es un Error

Ser honesto: late no es siempre correcto.

Para mutaciones iniciadas por el usuario, colaboración en tiempo real o presupuestos de latencia interactiva dura — el retraso solo mueve la espera.

Y la entrega distribuida tardía añade peligros reales:

→ Ordenación de mensajes.

→ Retry storms.

→ Hazard de idempotencia.

La madurez está en acotar dónde paga el retraso —lecturas, agregación, generación de informes— y dónde no —mutaciones con consecuencias inmediatas en la UI.

Otro matiz: diferir no es desaparecer. Un fetch tardío solo funciona si está enmascarado con skeletons, placeholders y prefetch especulativo en hover o focus. Para datos críticos por encima del fold, el eager es correcto. La cuestión no es elegir uno u otro: es dejar de hacer eager por accidente.

El Marco de la Última Responsabilidad (MLR)

Si queréis llevar esto a vuestro código hoy, sin teoría, aplicad este marco:

Paso 1: Auditoría de cada fetch saliente

Clasificad cada petición en vuestra app. ¿El dato se renderiza por encima del fold al montar? ¿O se fetchea "por si acaso"?

Etiquetad cada llamada: `EAGER-NEEDED`, `EAGER-UNNEEDED` o `LATE-READY`.

La auditoría sola revela un conjunto de fetches que ningún path de usuario dispara jamás.

Paso 2: Política de staleness explícita ANTES de tocar arquitectura

Configurad `staleTime`, `refetchOnFocus` y `refetchOnReconnect` deliberadamente en vuestra capa de datos (TanStack Query, SWR o equivalente).

Es la única forma de que el refetch temprano deje de ser el default accidental.

Paso 3: Cambiad el contrato cuando supere vuestro presupuesto

Para cualquier operación de servidor estimada por encima de vuestro presupuesto de respuesta bloqueante (unos pocos cientos de milisegundos), cambiad a: `POST → 202 { jobId }` + `GET /jobs/:id` + webhook/SSE opcional.

El GET debe ser idempotente y cacheable.

Paso 4: Arreglad el over-fetching en la fuente

Habilitad selección de campos dispersa (sparse fieldsets en JSON:API o selección de campos en GraphQL) y batched el fan-out server-side con un coalescer tipo DataLoader.

Una query batched tardía reemplaza a N llamadas eager.

Paso 5: Hardeneded la ruta async como un SLA de primera clase

Exigid claves de idempotencia en endpoints 202. Deduplicad server-side. Usad exponential-backoff para la entrega de webhooks. Añadid timeout/deadline en el cliente para que una respuesta tardía genuinamente perdida no cuelgue la UI para siempre.

Tratad el late como un contrato, no como un accidente.

Conclusión

Los equipos llevan una década pagando un impuesto invisible: fetches eager que nadie pidió, refetches accidentales que el default de `staleTime: 0` garantiza, y acoplamiento síncrono donde un 202 habría resuelto el problema con un endpoint de estado.

El patrón Late no es pereza. Es ingeniería de precisión: pides el dato cuando es visible, cuando el batch está lleno, cuando el servidor ha confirmado el trabajo — y no un segundo antes.

Mientras las APIs de redes sociales sigan degradando a quien consulta de forma eager e imprevisible, la ventaja competitiva en 2026 será de quienes traten la incertidumbre como primer principio. La tesis es sencilla: quien sabe esperar al último momento responsable —ni más tarde, ni, sobre todo, más pronto— construye sistemas que escalan porque no piden nada que no vayan a usar.

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 relato dominante dice que Next.js es la apuesta segura. Mayor pool de contratación de React. La mejor documentación. El respaldo de Vercel. Elegir al líder del mercado es elegir bajo riesgo.

*El problema: eso dejó de ser cierto en octubre de 2022. *

Tres años. Cuatro versiones mayores. Next.js 13, 14, 15 y 16 rompieron sus propios defaults cada ~12 meses. Renombró su fichero de middleware a `proxy.ts`. Eliminó caches que venían activadas por defecto. Movió todo el modelo de renderizado —de "server-side rendering para SEO" a React Server Components ejecutándose en el servidor por defecto. Y el "safe choice" sigue ahí: tu app compila, tus tests pasan, todo funciona.

Hasta que un tutorial de 2023 ya no cuadra con tu versión y no sabes por qué.

El verdadero Next.js actual no es el framework conservador que elegiste en 2022. *Es la apuesta más radical y con más velocidad de cambio de toda la infraestructura front-end de React. *

El mito de la página: tu código de 2022 ya es legacy

Cuando Next.js se lanzó en 2016 dentro de ZEIT (ahora Vercel), la arquitectura se estabilizó alrededor del Pages Router. El directorio `pages/`, con `getStaticProps` y `getServerSideProps`. Esa arquitectura fue la identidad del framework durante las versiones 7 a 12.

El modelo mental era una elección triple por página: `<b>estática</b>` (getStaticProps), server-rendered (getServerSideProps) o client-side. SEO. SSR. Rendimiento. Cada página elegía su camino.

En Next.js 13 (octubre 2022), Vercel introdujo el App Router como beta. En Next.js 14 (octubre 2023), lo convirtió en el default estable y recomendado. Y con él llegó React Server Components, convenciones de fichero nuevas (`layout.tsx`, `page.tsx`, `loading.tsx`, `error.tsx`) y un cambio conceptual: ya no eliges entre estático y dinámico *por página*.

Ahora un componente simplemente se ejecuta en el servidor a menos que optes por salir con `'use client'`.

Traducido: una base de código escrita en el idioma dominante de 2022 —Pages Router + getServerSideProps— es hoy técnicamente legacy. No puede usar Server Components. Requiere una reescritura completa para el App Router. Y la comunidad, los cursos y mil tutoriales de hace dos años enseñan exactamente esa arquitectura obsoleta.

❌ Enfoque incorrecto: "Tenemos SSR para SEO, buscamos una migración incremental del Pages al App Router."

✅ Enfoque correcto: "El App Router no es una versión mejorada del Pages Router. Son dos mundos distintos que comparten React debajo."

Mira la misma página de blog en los dos mundos. Pages Router, 2022:

```tsx

// pages/blog/[slug].js — Pages Router (2022)

export async function getStaticPaths() {

const posts = await getAllPostSlugs()

return { paths: posts.map(p => ({ params: { slug: p.slug } })), fallback: 'blocking' }

}

export async function getStaticProps({ params }) {

const post = await getPostBySlug(params.slug)

return { props: { post }, revalidate: 3600 }

}

export default function BlogPage({ post }) {

return <article>{post.title} {/ HTML plano, sin interactividad trivial /}</article>

}

```

App Router, hoy:

```tsx

// app/blog/[slug]/page.tsx — App Router (2025/2026)

export async function generateStaticParams() {

const posts = await getAllPostSlugs()

return posts.map(p => ({ slug: p.slug }))

}

// Este componente SÍ está en el servidor. Ejecuta su query ahí mismo.

export default async function BlogPage({ params }) {

const post = await getPostBySlug((await params).slug) // params es async en v15/v16

return <article>{post.title}</article>

}

```

No es una refactorización cosmética. El modelo mental completo —"el servidor existe para SEO, el cliente para interactividad"— se ha colapsado. En el App Router, el servidor es el punto de partida. El cliente es la excepción declarada con `'use client'`, que no es un toggle de hidratación: *es una directiva de frontera de módulo. *

El golpe silencioso: el culebrón del cacheo entre v13/v14 y v15

Aquí es donde los tutoriales viejos son más peligrosos.

El App Router temprano (v13/v14) era estático-por-defecto. Las llamadas `fetch` quedaban cacheadas implícitamente. Los GET Route Handlers se cacheaban. El Router Cache del cliente guardaba resultados. Código escrito en 2023 era instantáneo — no porque fuera rápido, sino porque todo estaba en cache.

Next.js 15 (octubre 2024) dio la vuelta a esos defaults. Los GET Route Handlers ya no se cachean por defecto. El Router Cache del cliente, tampoco. Y las request APIs (`cookies`, `headers`, `params`) se volvieron async.

Mira lo que eso significa con un ejemplo concreto. Un GET Route Handler escrito en el estilo v14:

```ts

// app/api/posts/route.ts — Estilo v14: cacheado implícitamente

export async function GET() {

const posts = await db.posts.findMany()

return Response.json(posts)

}

```

En v13/v14, ese handler se cacheaba automáticamente. En v15 y v16, determinará el renderizado dinámico de la ruta porque un componente que depende de esa respuesta ya no puede cachearse. Para recuperar salida estática, tienes que optar explícitamente:

```ts

// app/api/posts/route.ts — Realidad v15/v16: opt-in explícito

export const dynamic = 'force-static'

export async function GET() {

const posts = await db.posts.findMany()

return Response.json(posts)

}

```

Página instantánea en 2023 porque estaba cacheada. Round trip de red en 2025 porque nadie leyó las release notes. *La regresión silenciosa de rendimiento es el coste real de "semver majors con defaults cambiados". *

Y esto afecta a otro patrón que la mayoría lleva en producción: los Server Actions. La mutación de datos ya no necesita un Route Handler de API. Un formulario en un Server Component puede mutar directamente con una función async:

```tsx

// app/profile/form.tsx — Server Action (v15/v16)

export default function ProfileForm() {

async function updateName(formData: FormData) {

'use server'

const name = formData.get('name')

await db.users.update({ where: { id: user.id }, data: { name } })

}

return (

<form action={updateName}>

<input name="name" />

<button type="submit">Guardar</button>

</form>

)

}

```

Nada de esto existía en 2022. Y reescribe cómo piensas sobre APIs y endpoints.

Next.js 16: Turbopack, proxy.ts y el cinturón que se aprieta otra vez

La cadencia no se ha detenido. Next.js 16 (octubre 2025) hizo estable a Turbopack como bundler para dev y producción, renombró `middleware.ts` a `proxy.ts` y eliminó el acceso síncrono a `params`.

Un middleware que en v13–v15 protegía rutas con auth:

```ts

// middleware.ts — v13 a v15 (ahora obsoleto en v16)

import { NextResponse } from 'next/server'

export function middleware(request) {

const token = request.cookies.get('session')

if (!token && request.nextUrl.pathname.startsWith('/dashboard')) {

return NextResponse.redirect(new URL('/login', request.url))

}

return NextResponse.next()

}

export const config = { matcher: '/dashboard/:path*' }

```

Su equivalente en v16, renombrado y con API async:

```ts

// proxy.ts — v16 (renombrado desde middleware.ts)

export default async function proxy(request: Request) {

const token = request.headers.get('cookie') // ahora es un Request estándar

if (!token?.includes('session') && new URL(request.url).pathname.startsWith('/dashboard')) {

return Response.redirect(new URL('/login', request.url))

}

return undefined // continúa el flujo

}

```

Cuatro majors en tres años. 13→14→15→16. La app mediana de producción está uno o dos majors por detrás. Y cada hueco se agranda: params/headers síncronos → async, middleware → proxy, Pages → App, webpack → Turbopack.

No solo eso: Next.js absorbe los cambios ascendentes de React. La v13 ya ship-eó Server Components antes de que React 19 los estabilizara oficialmente. El framework lidera la curva, y luego rompe sus propias APIs encima.

Para managers técnicos, esto tiene una consecuencia dura: *"Senior React Developer" ya no es suficiente. Necesitas gente que lea las release notes de Next.js cada año. *

El Patrón del Impuesto de Versión: cómo no quedarte en la cola

Aquí va mi método para operar bajo esta cadencia. Lo llamo el El Patrón del Impuesto de Versión. Cinco pasos, cada vez que toques un proyecto Next.js:

Paso 1 — Fija tu versión y presupuesta el impuesto. Trata cada release mayor (anual desde 2022) como un proyecto de migración, no como una actualización de rutina. Antes de tocar tu código de app, lee el Upgrade Guide oficial y ejecuta los codemods:

```bash

npx @next/codemod@canary upgrade

```

Paso 2 — Decide tu identidad de Router hoy. Si estás en Pages Router, asume una reescritura completa hacia App Router, no un retro-portado incremental. Lista qué rutas son interactivas vs de contenido para conocer tu frontera servidor/cliente.

Paso 3 — Toma una decisión de hosting explícita en el mes uno. Vercel-first frente a self-hosting con output Node.js standalone (`output: 'standalone'`, Docker). Muchas capacidades del App Router —ISR bajo demanda, optimización de imagen en el edge, soporte a PPR— tienen implementaciones de primera clase en Vercel y costes operativos distintos si te auto-alojas. Retrofitar esto después es de donde nacen las reescrituras.

Paso 4 — Audita tus asunciones de cacheo contra la versión actual. Ejecuta `next build` e inspecciona la tabla de rutas. Mira qué rutas son estáticas, dinámicas o ISR. Re-añade `generateStaticParams`, `force-static` o la revalidación con semántica `'use cache'` donde de verdad quieras salida estática. *No copies ejemplos v13/v14 verbatim. *

Paso 5 — Añade observabilidad y una página de pruebas canary para RSC. La gestión de datos ahora ocurre en el servidor, dentro de componentes. Los waterfalls y los error boundaries (`error.tsx`, `global-error.tsx`) hay que probarlos en producción, no solo en dev.

¿Y el argumento del SEO?

La frase "SSR para SEO" —la razón clásica para elegir Next.js— es un modelo mental muerto. En 2026, SSR ya no es la feature titular. Lo que determina el rendimiento es el split compilación/request: salida estática, ISR, dinámico y el PPR experimental (Partial Prerendering). Para sitios dominados por contenido, una estrategia estática/ISR gana a renderizar cada petición en el servidor.

SSR es una capacidad y un coste. No una garantía de rendimiento. El propio Next.js 15 osciló hacia render dinámico precisamente porque cachear no es gratis.

Dónde queda el lock-in

El lock-in no es binario. No es cierto que App Router requiera Vercel: con `output: 'standalone'` te auto-alojas en Node.js o Docker, y RSC/Server Actions son HTTP plano. El lock-in práctico es la completitud de features —on-demand ISR, optimización de imagen en el edge, soporte tight de PPR— que están productivizadas en Vercel y que en self-hosting tienes que ensamblar tú mismo o aceptar estático puro.

La competencia real de Next.js no son "otros frameworks React". Es la asunción por defecto de que una app React tiene que ser una Next.js app. React Router (framework mode) y Astro atienden a la misma audiencia con tradeoffs distintos: React Router mantiene un modelo request/response más cercano al SSR clásico; Astro empuja server-first con islas y envía cero JavaScript por defecto.

Next.js aporta una gravedad de ecosistema inigualable y la madurez de Server Components más grande del mercado. *A cambio, cobra el impuesto de migración anual más alto y ejerce la atracción más fuerte hacia un único vendor de hosting. *

Conclusiones

El relato de la "apuesta segura" te lo venden desde 2016. Desde 2022, la evidencia es la contraria:

→ Los defaults se rompen cada ~12 meses. V13, v14, v15, v16. Caches, middleware, request APIs, bundler. Todo ha cambiado en tres años.

→ El código de hace dos años es legacy. Pages Router, getServerSideProps, fetch cacheado implícitamente — toda esa arquitectura es historia.

→ Migrar no es un evento. Es un ritmo. Dentro del propio App Router, v14→v15 cambió defaults de cacheo y v15→v16 renombró middleware y forzó params async. Tu código App Router de 2023 necesita reescritura en 2026.

La pregunta no es si Next.js es "seguro". Es si estás presupuestando el impuesto de versión que cobra cada octubre. Los equipos que lo hacen —apiñando el upgrade, auditando cacheo contra la versión actual, decidiendo su hosting en el mes uno— siguen operando a toda velocidad. Los que esperaban estabilidad llevan tres años de retraso sin darse cuenta.

Next.js no es el default aburrido que eligiste por seguridad. Es la base tecnológica más veloz de React, y la única forma de sobrevivirla es tratarla como lo que es: un framework que te obliga a migrar cada año.

La próxima vez que alguien diga "Next.js es lo seguro", pregúntale qué versión tiene en producción. Esa respuesta te dirá más que mil debates de arquitectura.

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 de precio es que no encuentras "el número correcto". Que si haces tres propuestas más, miras a la competencia, o aplicas la fórmula de coste + margen, la cifra mágica aparecerá.

*Te has equivocado de diagnóstico.*

Antes de preguntarte "¿cuánto cobro?" hay una pregunta anterior que ya ha condenado tu producto a morir en el mes 3. Y no tiene nada que ver con el número.

La mayoría de intentos de productizar un servicio fracasan en el primer año. Y la causa declarada no es el nivel de precio. Es el esquema de cobro: forzar recurrencia donde no la hay.

El suelo de precio no es un número que se calcula. Es una puerta binaria que solo se abre si el patrón de consumo subyacente es recurrente. Si no lo es, cualquier suelo que fijes — alto, bajo, exacto — es una condena diferida.

---

El Debate del "Cuánto" está Secuestrando al Debate del "Cómo"

La sabiduría convencional dice que el suelo de precio se descubre con fórmulas. Coste más margen. Valor entregado. Benchmark de competencia.

El material fuente apunta a lo contrario.

Hay dos variables distintas con las que se suele jugar mezcladas: "cuánto" (el nivel de precio) y "cómo" (el modelo de cobro). El fracaso del 90% en el primer año se explica por el segundo, no por el primero.

Esto implica algo incómodo: una obsesión por encontrar el número correcto es una fuga hacia adelante cuando el modelo de cobro fuerza recurrencia sobre un consumo único.

No hay suelo de precio que arregle un problema de inexistencia de producto recurrente. Ninguno. Puedes poner el número que quieras. Si tu modelo de cobro no encaja con el patrón de consumo, el suelo es decoración sobre una base podrida.

---

La Única Pregunta que Decide Todo: ¿Datos Vivos o Informe Estático?

Aquí está el punto donde casi todos se pierden. Porque la pregunta que separa un servicio que puede llevar recurrencia de uno que no la soporta es binaria.

Si tu entregable es un informe estático — un PDF de auditoría, una migración completada, un análisis puntual —, estás vendiendo un artefacto de consumo único. Quien lo recibe lo lee una vez, lo archiva, y no vuelve a necesitarlo.

Si defender un suelo recurrente sobre eso, estás fabricando recurrencia.

Y aquí es donde entra la mecánica del fracaso. Cuando fuerzas un modelo de ingresos recurrentes sobre una necesidad de consumo único, algo tiene que ceder. Y lo que cede es la renovación.

❌ Modelo débil: "Vendo informes de SEO mensuales recurrente porque necesito ingresos predecibles." El cliente consume una vez y cancela en el mes 3.

✅ Modelo fuerte: "Vendo un panel de datos vivo que se actualiza continuamente y exige operación constante para seguir funcionando." El cliente renueva porque el estado muere si lo deja.

El objeto de precio cambia por completo. De documento entregado a estado mantenido.

---

La Mecánica del Hito del Mes 3: Cuando la Relación Deja de Pagar

¿Por qué el mes 3? Porque no es casualidad que las ofertas "recurrente-as-a-servicio" (RaaS) sin consumo real mueran sistemáticamente alrededor del primer trimestre.

La mecánica es predecible. Durante los primeros meses, la renovación la sostienen tres muletas:

1. El entusiasmo del onboarding. Todo es nuevo, hay momentum, el cliente está comprometido emocionalmente.

2. La novedad. El entregable se ve, se evalúa, se comenta.

3. La relación interpersonal. Y aquí está la trampa más peligrosa.

Alrededor del tercer mes, esas tres muletas se retiran. Y lo único que queda sobre la mesa es una pregunta seca: ¿el estado de datos u operación que vendes realmente se consume de forma recurrente?

Si la respuesta es no, el cliente cancela. No porque el precio fuese caro. No porque el trabajo fuese malo. Sino porque el consumo no se repitió, y pagar por algo que no consumes es absurdo para cualquier comprador racional.

Por eso la mortalidad se concentra en ese punto: es el momento exacto en que la relación deja de pagar y el producto empieza a facturar — o no.

---

El Primer Cliente Feliz es una Trampa Estadística Doble

Y aquí entra el error de validación más caro que cometerás en todo el proceso.

Tu primer cliente satisfecho no valida un producto. Valida una relación interpersonal cuyo pago de repetición es una incógnita.

¿Qué significa eso para tu suelo de precio?

Que su disposición a pagar no mide el valor de tu producto. Mide cómo se siente contigo. Mide la afinidad, la confianza, el favor que te debe porque le resolviste algo en persona.

Extrapolar un suelo de precio desde ese único punto de datos comete el mismo error de validación que ya cometió quien confundió un favor con un producto. El primer cliente no es una muestra representativa del mercado: es una muestra representativa de una relación.

La consecuencia operativa es directa. La única señal de precio que vale es el pago de repetición de alguien que ya no te debe un favor. Si ese dato no existe, tu suelo de precio sigue siendo una especulación disfrazada de decisión.

---

El Modelo del Suelo Binario: 5 Pasos para Fijar el Suelo Como Función del Consumo, No del Coste

Este es el framework El Modelo del Suelo Binario — puerta de consumo, no fórmula de coste. Cinco pasos, en orden estricto. No los saltes.

Paso 1 — Clasifica Antes de Numerar

Responde la pregunta de diagnóstico sobre tu entregable real, no sobre el que te gustaría vender: ¿entrega datos vivos o un informe estático?

Si la respuesta honesta es "informe estático", tu problema de suelo está mal planteado desde el origen. Puedes productizarlo — claro que sí — pero el suelo y el modelo de cobro deben corresponder al consumo único o al estado recurrente adyacente. No a una suscripción forzada.

La alternativa es aceptar abiertamente el modelo de proyecto, sin disfrazarlo de recurrente. Duele menos que fingir recurrencia y morir en el mes 3.

Paso 2 — Define el Estado Recurrente Productizable

Si tu entregable es un informe anual de seguridad laboral, pregunta: ¿qué estado queda vivo entre una entrega y la siguiente? ¿Los riesgos cambian? ¿Hay normativa nueva? ¿Hay datos que se actualizan?

Ese estado de datos u operación que permanece vivo entre entregas y que dispara tu trabajo de forma periódica es el objeto sobre el que tiene sentido hablar de suelo. No el artefacto. El artefacto es una foto. El estado es la cámara funcionando para siempre.

Paso 3 — Valida la Hipótesis Contra el Mes 3

Antes de comprometer un suelo y un modelo de cobro, diseña una prueba que mida si el consumo se repite pasado el trimestre.

El mes 3 es el punto ciego de toda la teoría del suelo de precio. El entusiasmo inicial y la relación interpersonal dejan de sostener la renovación. Solo queda el consumo real.

Diseña la prueba. Mídela. No lances sin ese dato.

Paso 4 — Modela el Pago Según el Patrón Real

Solo ahora, cuando sabes si tu consumo es recurrente, por consumo puntual repetible o por proyecto, tiene sentido derivar el suelo.

El suelo se modela como función de la unidad de valor recurrente que mantienes viva — no del coste de producción del artefacto. Si lo que mantienes vivo requiere operación continua para seguir valiendo, esa operación es tu unidad de valor. Eso, y no el coste de escribir un informe, es lo que ancla el suelo.

Paso 5 — Recalibra con la Renovación del Primer Cliente

La única señal legítima de precio es el pago de repetición de alguien que ya no te debe un favor.

Si el primer cliente renueva pasado el mes 3, y puedes verificar que renueva porque el estado de datos sigue siendo valioso para él — no porque le caes bien —, tienes la primera muestra real de tu suelo.

Si no tienes ese dato, tu suelo sigue siendo una especulación. Y reconocerlo es más barato que fingir que sabes.

---

Las Objeciones Que Vas a Tener (y sus Respuestas)

"Mi servicio es genuinamente de consumo único. ¿No puedo productizarlo?"

Sí puedes. Pero el suelo y el modelo de cobro deben corresponder al consumo único o al estado recurrente adyacente. Si vendes migraciones de datos, no fuerces una suscripción de "mantenimiento de migración". O acepta el modelo de proyecto sin maquillarlo de recurrente, o encuentra el estado vivo que queda después de la migración — el sistema operativo, los accesos, los backups vivos.

"Mis clientes renuevan más allá del mes 3."

Entonces la hipótesis de recurrencia se confirma. Pero verifica la causa: ¿renuevan porque el estado de datos sigue vivo y trabajando, o porque siguen pagando por la relación interpersonal con quien les vendió?

Renovar por relación es la misma trampa del primer cliente, diferida unos meses. Y se nota en un dato: si solo renuevan los clientes que te conocen en persona y no los que llegan por inbound publicitado, estás cobrando confianza, no producto.

"¿No necesito un suelo bajo para ganar a los primeros clientes?"

Confundes suelo con descuento comercial. El suelo es la puerta del modelo, derivada del patrón de consumo. El descuento es una táctica de adquisición.

Regalar descuentos por debajo del suelo no valida tu modelo: lo contamina. Convierte la muestra del primer cliente en todavía menos representativa de lo que ya era. Un cliente que te compra a mitad de precio por afinidad es la peor evidencia posible para fijar el suelo definitivo.

---

Una Nota de Honestidad Metodológica

La cifra del 90% de fracaso en el primer año y la evidencia de los RaaS que mueren en el mes 3 provienen del propio material de partida, no de una estadística externa auditada.

Úsalas como lo que son: hipótesis de trabajo, no datos verificados.

Y esa misma cautela refuerza el argumento central. Si ni siquiera las cifras del sector están auditadas, cualquier suelo de precio calculado en abstracto vale todavía menos. La única fuente de validación que existe son las renovaciones reales de clientes que ya no te deben nada.

---

La Idea Que Te Llevas

El suelo de precio no es un número que se calcula antes de lanzar. Es una consecuencia que solo existe si el patrón de consumo es recurrente.

Deja de calcular. Empieza a clasificar.

Pregunta primero si tu entregable es datos vivos o informe estático. Encuentra el estado recurrente que queda vivo entre entregas. Valídalo contra el mes 3. Modela el pago según el consumo real. Y recalibra con la única señal que vale: el pago de repetición de alguien que ya no te debe un favor.

La mayoría de los que creen tener un problema de precio tienen en realidad un problema de inexistencia de producto recurrente. Y ningún suelo, por bajo o por alto que sea, lo arregla.

Hazlo bien y el número dejará de ser una conjetura. Será una consecuencia.

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 mundo no está construyendo agentes. Está reimplementando un loop que ya está resuelto.*

La mayoría de vosotros habéis construido "agentes" así: llamada al modelo, prompt gigante, un bucle manual que parsea tool calls, maneja errores, reintenta, gestiona contexto... y reza por que en producción no se rompa.

Eso era razonable en 2024.

En 2026, Anthropic ha distribuido como paquete npm (`@anthropic-ai/claude-agent-sdk`) el mismo loop de agente que potencia Claude Code. El agente planifica, usa herramientas y itera de forma autónoma. No es una API de chat con esteroides. Es el agente entero, empaquetado, versionado y mantenido.

Esto ya no es un problema de ingeniería. Es un problema de configuración.

Y casi todo el mundo lo está haciendo mal.

<br>

El Problema: Seguís Pagando el Peaje de una Abstracción que ya no Necesitáis

El argumento convencional dice que construir un agente significa elegir un framework de orquestación — LangChain, CrewAI, AutoGen, LangGraph — y montar tú mismo los prompts, las llamadas al modelo y las herramientas.

El SDK invierte esa suposición por completo.

❌ El enfoque heredado: Ciento cincuenta líneas de orquestación casera. Cada equipo reimplementa el plan-actúa-observa-itera a mano, lo depura durante semanas y lo rompe en producción.

✅ El enfoque del Claude Agent SDK: Importas el SDK, defines qué herramientas expones, qué permisos concedes y cuántas iteraciones permites. El loop — la parte más difícil, frágil y propensa a errores de cualquier agente — ya está escrito, endurecido y desplegado dentro de Claude Code.

El valor marginal de escribir tu propia orquestación colapsa.

Esto no es especulación. Es la diferencia entre reimplementar React a mano y usar React porque el DOM ya lo resuelve alguien que lleva años depurándolo en producción.

<br>

La Evidencia: El Loop es el Producto, no un Detalle de Implementación

Mirad lo que expone el SDK en su superficie pública. No es un constructor de prompts. Es la infraestructura del agente como API:

Dos modos de entrada que mapean a necesidades de control distintas:

• `query()` — para un resultado simple y streameado

• `streamQuery()` — para control granular del ciclo de vida con soporte de `AbortSignal`

Sistema de herramientas embebido: El SDK trae el toolset completo de Claude Code — `Bash`, `Read`, `Write`, `Edit` — sin que tengas que implementar ni uno. Las capacidades web y de búsqueda llegan vía conexiones MCP servers.

Gobernanza como parámetro de primera clase: `allowedTools`, `permissionMode`, y límites de ejecución como `maxTurns` y `maxTokens` son opciones de configuración, no ideas de último momento.

Persistencia de sesión: Hooks y checkpoints con `resume`. Una sesión se puede pausar, inspeccionar y continuar. No es fire-and-forget.

Aquí está el código mínimo de un agente funcional:

```typescript

import { query } from '@anthropic-ai/claude-agent-sdk';

const result = await query({

prompt: 'Revisa el fichero src/main.ts, encuentra las vulnerabilidades y aplícalas.',

options: {

allowedTools: ['Bash', 'Read', 'Edit'],

permissionMode: 'acceptEdits',

maxTurns: 25,

},

});

for await (const message of result) {

if (message.type === 'assistant') {

console.log(message.message.content);

}

}

```

Diez líneas. Un agente autónomo que lee, edita y ejecuta. Sin framework. Sin bucle manual. Sin orchestrator.

Si alguien te dice que necesitas LangChain para esto, te está vendiendo una abstracción que ya no necesitas.

<br>

El Análisis: Qué Significa que el Fabricante del Modelo Posea el Loop

Esto no es solo una mejora de developer experience. Es un cambio estructural del mercado.

Cuando el vendor del modelo posee el loop y opcionalmente el runtime — vía la gestionada Claude Agent API — el diferenciador para los desarrolladores deja de ser el código de orquestación.

*El diferenciador es la configuración.*

Qué herramientas expones. Qué permission modes activas. Cómo modelas los checkpoints para revisión humana. Esas son las superficies donde un agente real triunfa o fracasa.

Y hay una segunda implicación más profunda: las salvaguardas han dejado de ser un truco de prompt engineering.

Antes, la seguridad de un agente dependía de escribir "por favor, no ejecutes comandos destructivos" en el prompt. Ahora es un contrato enforceable y auditable vía `permissionMode` y `allowedTools`.

Eso es precisamente lo que hace que los agentes autónomos sean aprobables dentro de organizaciones reguladas. La seguridad ya no es una súplica al modelo. Es una propiedad de la API.

<br>

El Método del Permiso por Diseño: Cómo Llevar un Agente del Demo al Producto

Todos los tutoriales te enseñan a hacer el agente funcionar. Casi ninguno te enseña a hacerlo seguro, gobernado y recuperable. Ese es el salto del demo al producto. Yo lo llamo El Método del Permiso por Diseño, y tiene cinco pasos:

Paso 1 — Instala y verifica antes de escribir código de features.

Crea un proyecto Node/TypeScript, añade `@anthropic-ai/claude-agent-sdk`, configura credenciales y ejecuta un hello-world. Confirma el requisito de servidor Node — esto no se ejecuta en el navegador, comunica vía Server-Sent Events — y examina los entry points del SDK antes de tocar nada más.

Paso 2 — Elige tu modo de ejecución con intención.

Empieza en modo local con `query()`/`streamQuery()` contra la API del modelo. Solo más tarde evalúa la gestionada Claude Agent API si quieres que Anthropic opere el runtime, los reintentos y el escalado por ti.

Paso 3 — Limita el poder del agente antes de darle herramientas.

Esto es el corazón del método:

```typescript

import { streamQuery } from '@anthropic-ai/claude-agent-sdk';

const controller = new AbortController();

const result = await streamQuery({

prompt: 'Refactoriza el módulo de facturación manteniendo la API pública.',

options: {

allowedTools: ['Bash', 'Write', 'Edit'], // Solo lectura + edición acotada

permissionMode: 'default', // Pide confirmación para lo destructivo

maxTurns: 40, // Presupuesto de ejecución duro

maxTokens: 100_000, // Presupuesto de tokens duro

},

signal: controller.signal,

});

for await (const event of result) {

switch (event.type) {

case 'init': console.log('Sesión iniciada:', event.sessionId); break;

case 'agent_message': console.log('Agente:', event.message.content); break;

case 'tool_use': console.log('Tool:', event.name, JSON.stringify(event.input)); break;

case 'result': console.log('Tarea completada'); break;

}

}

// Para cancelar un agente desbocado a mitad de ejecución:

controller.abort();

```

Tratad los permisos como parte de vuestro diseño de API, no como una idea de seguridad de último momento. El `AbortSignal` aquí no es un extra. Es la diferencia entre un agente desbocado que cuesta tokens y uno que se puede detener.

Paso 4 — Añade capacidades reales vía tools y MCP, no engordando prompts.

Nada de prompt-hacking. Extender el agente es declarativo. Un custom tool se define con schema:

```typescript

// registrar.ts

import { query } from '@anthropic-ai/claude-agent-sdk';

// Con un MCP server, el agente descubre y llama las tools del protocolo estándar

const result = await query({

prompt: 'Consulta la base de datos de clientes y resume los impagos del último trimestre.',

options: {

mcpServers: {

postgres: {

command: 'npx',

args: ['-y', '@modelcontextprotocol/server-postgres'],

env: { POSTGRES_CONNECTION_STRING: process.env.DATABASE_URL! },

},

},

permissionMode: 'default',

},

});

```

Aquí está el giro estratégico: gran parte de la "ingeniería de agentes" se convierte en curación de MCP servers. Igual que la gestión de dependencias define la mayor parte del trabajo backend tradicional, declarar MCP servers define la mayor parte del trabajo con agentes. Reutilizas el ecosistema MCP existente en lugar de escribir código de conexión a medida para cada fuente de datos.

Y MCP es lo que evita el lock-in aburrido. No escribes connectors bespoke para cada API. Declaras servers y el agente consume lo que el ecosistema ya ofrece.

Paso 5 — Productiviza el ciclo de vida de la sesión.

Este es el paso que separa el demo del producto. Necesitáis:

1. Hooks para logging y aprobación humana — wire up un hook para auditar cada tool call

2. Persistencia de checkpoints — que una tarea larga se pueda pausar, inspeccionar y continuar

3. Resume para trabajos largos — sesiones recuperables, no fire-and-forget

```typescript

import { query } from '@anthropic-ai/claude-agent-sdk';

// Simula el control de sesión: hooks que pausan la ejecución

// y checkpoints que permiten inspeccionarla y resumirla

const result = await query({

prompt: 'Migra los datos del CSV antiguo a la nueva tabla normalizada.',

options: {

allowedTools: ['Bash', 'Read', 'Write', 'Edit'],

permissionMode: 'default',

hooks: {

PreToolUse: (hookInput) => {

console.log('[AUDIT] Tool a punto de ejecutarse:', hookInput.toolName);

// Devuelve approval para controlar ejecuciones sensibles

return { behavior: hookInput.toolName === 'Bash' ? 'deny' : 'allow' };

},

Stop: async () => {

console.log('[CHECKPOINT] Guardando estado de sesión...');

// Persiste aquí el checkpoint para un futuro resume

},

},

maxTurns: 60,

},

});

for await (const message of result) {

if (message.type === 'result') {

console.log('Resultado final:', message.result);

}

}

```

Aquí es donde el SDK demuestra que no es solo "el CLI de Claude Code con gabardina". Un wrapper de subprocess o una llamada chat cruda no exponen la superficie de embedding que sí expone el SDK: checkpoints, resume, hooks, permission modes y `AbortSignal`.

<br>

Objeción 1: "¿Y el lock-in? ¿Mis tool calls y mi estado pasan por infraestructura de Anthropic?"

Distinguid los dos modos, porque son muy distintos:

Modo local: El SDK ejecuta el loop en tu servidor Node. Las llamadas al modelo van a un endpoint compatible con Anthropic — incluyendo Bedrock o Vertex si ya estáis ahí. Tus tool calls y tu estado no pasan por la infraestructura gestionada de Anthropic.

Gestionada Claude Agent API: Anthropic opera el runtime, los reintentos y el escalado. Aquí sí, tus outputs de herramientas y estado intermedio viven en un runtime del vendor. Conveniente, pero cambia la forma de tus decisiones de portabilidad multi-modelo y residencia de datos.

La respuesta honesta no es fingir que no hay trade-off. Es ser explícito sobre qué deja tu control en cada modo. Si la residencia de datos es dura en tu sector, modo local con Bedrock/Vertex. Si quieres escalar sin operar infraestructura, gestionada.

<br>

Objeción 2: "¿Por qué no OpenAI Agents SDK, LangGraph o un framework abierto multi-modelo?"

Este es un trade-off, no una victoria. El Claude Agent SDK es TypeScript-first y está lockeado al modelo de Anthropic. A cambio compras comportamiento de agente turnkey y un runtime opinado.

❌ Elegís por moda: Framework que soporta 47 modelos porque "da flexibilidad". Nunca usáis 46 de ellos. Pagáis el coste de abstracción por un caso que no vais a tener.

✅ Elegís por criterio: ¿Estás comprometido con un solo vendor y quieres el loop más endurecido disponible? Claude Agent SDK. ¿Necesitas portabilidad multi-modelo como requisito arquitectónico real — no hipotético? Evalúa LangGraph o semejantes.

La pregunta no es "cuál es mejor". Es "¿cuánto vale un loop endurecido para ti y qué estás dispuesto a ceder en portabilidad?".

<br>

Objeción 3: "Ya puedo hacer shell out al CLI de `claude` o llamar a la API con mi propio loop. ¿Qué añade un SDK?"

El CLI te da un agente, pero no te da una superficie de integración. No puedes exponer programáticamente checkpoints, hooks, `permissionMode` ni `AbortSignal` desde un subprocess wrapper.

Un raw chat call te da un modelo, pero te obliga a ti a reimplementar el loop entero — planificación, iteración, gestión de contexto, manejo de errores.

*El SDK no es el agente en otro formato. Es la superficie de embedding que ni el CLI ni una chat call te dan.* Y es un agente mantenido y versionado, no un prompt loop que forkaste en 2024 y que arrastras desde entonces.

<br>

Conclusión: La Ingeniería de Agentes se Ha Convertido en Configuración

Lo que os llevó meses construiros — el loop de plan-actúa-observa-itera — ahora es una dependencia que actualizáis con `npm install`.

El trabajo que queda es más interesante, no menos. Diseñar qué herramientas exponer. Definir los límites de permisos como parte del diseño de API. Modelar checkpoints para revisión humana. Construir harnesses de evaluación que midan a vuestro agente contra casos reales.

Las claves para llevarte hoy:

• El loop es el producto. Dejad de reimplementarlo.

• Los permisos no son una idea de último momento. Son tu diseño de API.

• MCP es vuestra capa de integración. Curación de servers, no código bespoke.

• Los checkpoints y hooks separan el demo del producto.

• Sed explícitos sobre qué modo de ejecución usáis — y qué sale de vuestro control en cada uno.

En 2024, construir un agente era un problema de ingeniería que casi nadie resolvía bien. En 2026, es un problema de configuración que casi cualquiera puede ejecutar — si entiende qué configurar y por qué.

Los que sigan cableando prompts y funciones a mano dentro de dos años no estarán "construyendo agentes". Estarán pagando el peaje de una abstracción que ya nadie necesita.

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

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