Sistema operativo de adquisición de enlaces

Un negocio de adquisición de enlaces había entregado miles de backlinks a agencias y clientes directos durante varios años. Los clientes encargaban enlaces para mejorar la autoridad y la visibilidad en buscadores de sus sitios web; la operación buscaba editores adecuados, evaluaba su calidad, negociaba las tarifas de colocación y gestionaba cada pedido hasta su publicación y su pago.

El negocio en sí estaba sano. El modelo operativo, no.

La prospección, la evaluación, el contacto, la negociación y la gestión de pedidos estaban repartidos entre los SOP, Airtable, Pitchbox y buzones compartidos, con el apoyo de un equipo de seis personas. Cuando empecé la reconstrucción, los pedidos tardaban en promedio unos 80–88 días en publicarse y solo el 2,5 % se entregaba en 30 días.

El equipo estaba formado por un gerente, una persona encargada del contacto con editores y cuatro personas dedicadas a la gestión de pedidos.

El objetivo no era simplemente “añadir IA”. Era rediseñar la operación para que pudiera:

• incorporar nuevos editores a gran escala;
• aplicar un nivel de calidad constante;
• negociar tarifas de forma sistemática;
• entregar los pedidos más rápido;
• reducir los costos de herramientas y personal;
• conservar el criterio humano donde los errores salían caros;
• y crear un sistema que se pudiera medir y mejorar de forma continua.

Me encargué del proyecto de principio a fin: descubrimiento del proceso, especificación del sistema, arquitectura, modelo de datos, modelado de costos, implementación, pruebas, despliegue e iteración continua.

La plataforma también acumuló 1511 editores incorporados con tarifas acordadas, guardó 15 564 tarifas, importó 71 080 correos históricos y monitoreó más de 16 000 enlaces publicados.

Dónde empezamos

Antes de la nueva plataforma, la operación funcionaba con:

• Dos SOP por escrito
• Airtable
• Pitchbox
• Cuatro buzones compartidos
• Evaluación manual de editores
• Negociación manual
• Selección manual de colocaciones
• Seguimiento manual de pagos

El negocio en sí era rentable y estaba consolidado. Desde 2022 había entregado más de 16 000 enlaces a 42 clientes con márgenes sólidos. El problema era el proceso que lo rodeaba.

La prospección era manual

Una persona del equipo revisaba listas en Pitchbox, descartaba los sitios que claramente no encajaban, buscaba los datos de contacto y comprobaba a mano cada dominio según los criterios de calidad de la agencia. Eso incluía factores como:

• idioma;
• fecha de la publicación más reciente;
• volumen de artículos;
• si el sitio vendía enlaces abiertamente;
• indicios de PBN;
• restricciones de nicho;
• umbrales básicos de calidad.

La negociación era determinista sobre el papel y manual en la práctica

El SOP ya incluía:

• franjas de precio según el DR;
• una secuencia escalonada de ofertas en tres pasos;
• tiempos de seguimiento fijos.

Las personas ejecutaban a mano reglas que en gran parte ya estaban predeterminadas.

La gestión de pedidos vivía en una hoja maestra

Cuando un cliente encargaba un enlace, alguien seleccionaba a mano un editor, le escribía, daba seguimiento a la colocación, registraba la URL publicada y gestionaba el pago. A medida que crecía el volumen, ese proceso se volvía más difícil de gestionar de forma uniforme.

El síntoma más claro era la velocidad de entrega

El deterioro se veía trimestre a trimestre.

En abril y mayo de 2026, los pedidos tardaban en promedio 80–88 días en publicarse, y ninguno se publicó en 30 días.

Definir el sistema

El objetivo

En términos de negocio, el encargo era sencillo:

Contactar con miles de sitios al mes con una intervención humana mínima, mantener el nivel de calidad y convertir la base de datos de editores en una fuente sobre la que el sistema pudiera operar directamente.

El reto de fondo era que esto exigía rediseñar el proceso, no automatizar tareas sueltas. La operación existente había crecido en torno a personas, herramientas y hábitos. La nueva necesitaba reglas explícitas.

Una semana antes de escribir código

Dediqué alrededor de una semana a especificar el sistema antes de empezar la implementación. Eso incluyó:

• revisar los SOP existentes;
• entrevistar a quien dirigía el proceso;
• mapear el flujo de trabajo real en lugar de suponer que el SOP coincidía con la realidad;
• definir cada punto de decisión importante;
• diseñar el esquema de la base de datos;
• identificar las fuentes de datos externas;
• modelar los límites de las API y los costos probables;
• estimar la capacidad del sistema;
• separar las decisiones deterministas de las que requerían criterio;
• definir los puntos de aprobación humana.

La especificación de diseño se aprobó antes de la implementación, y después llegó un plan de ingeniería que fijó el esquema inicial, los límites entre módulos y los umbrales.

Esa secuencia se convirtió en una de las lecciones más importantes del proyecto:

Descubrir el proceso es parte de la construcción.

Saltárselo habría producido una primera versión más rápida del sistema equivocado.

Seis decisiones tomadas antes de construir

Varias decisiones sobre reglas de negocio se resolvieron antes de que pudieran convertirse en comportamientos accidentales del software.

• El encaje de nicho sería híbrido

  Los sitios se clasificarían a grandes rasgos durante la evaluación, pero la idoneidad para un cliente concreto se decidiría después, al asignar los pedidos. Un buen sitio no debía rechazarse para todos porque no fuera adecuado para un cliente.

• La detección de PBN sería equilibrada

  Las redes evidentes se podían rechazar automáticamente. Los casos dudosos pasarían a revisión humana en lugar de descartarse en silencio.

• La concentración del tráfico importaba

  Un sitio podía tener un tráfico llamativo y aun así ser de baja calidad si una sola página concentraba casi todo.

• La caída del tráfico necesitaba contexto

  Una caída de clics por sí sola no bastaba. La pérdida de tráfico combinada con un deterioro del posicionamiento decía más que el movimiento del tráfico aislado.

• Un DR muy alto no rechazaría automáticamente un sitio

  Un DR de 90 o más podía perder prioridad sin quedar excluido.

• Era necesario establecer un periodo de espera antes de volver a contactar

  No se debía volver a contactar con los editores sin dejar suficiente tiempo entre campañas.

Estas decisiones formaron parte de la especificación original del sistema.

La arquitectura

La plataforma se construyó como una aplicación propia en Python en torno a una base de datos MySQL. Entre las tecnologías principales estaban:

• Python
• MySQL
• FastAPI
• HTMX
• APScheduler
• Ahrefs
• DataForSEO
• Hunter
• Instantly
• OpenRouter / Claude
• Buzones IMAP/SMTP heredados

Pero la decisión de arquitectura más importante no fue el conjunto de tecnologías. Fue el modelo de integración.

La base de datos era el punto de integración

Cada worker interactuaba a través de la base de datos. Un worker:

Nada necesitaba llamar directamente a todos los demás subsistemas. Eso le dio al sistema varias propiedades útiles:

• los reinicios eran seguros;
• el trabajo podía reanudarse desde el último estado confirmado;
• las tareas se podían inspeccionar;
• los fallos se podían reintentar;
• los workers podían evolucionar de forma independiente;
• cada decisión tenía un historial persistente.

El principio de diseño era:

El estado se mueve a través de la base de datos. Los workers no dependen de que los demás estén activos en el mismo momento.

Eso hizo que la plataforma fuera mucho más fácil de operar que una larga cadena de automatización síncrona.

Las reglas deciden. La IA interpreta.

Esta fue la separación más importante de la plataforma. El sistema usaba IA, pero deliberadamente no la usaba para todas las decisiones.

La regla era explícita:

El LLM lee y escribe palabras. No fija precios ni inventa hechos del negocio.

El proceso de evaluación

Cada dominio encontrado podía pasar por hasta ocho etapas. La clave era que estaban ordenadas deliberadamente por costo, no por importancia percibida. Las primeras verificaciones descartaban a bajo costo los dominios claramente no aptos. Los datos caros solo se compraban para el grupo más pequeño que sobrevivía.

La secuencia general era:

1. ReglasListas de bloqueo
2. IAVerificación editorial / de seguridad de marca
3. DatosTráfico en el mercado
4. DatosDomain Rating (DR)
5. IACalidad del contenido
6. DatosPBN / análisis de calidad avanzado
7. ReglasContacto verificado
8. Contacto en frío

De los cerca de 25 000 dominios que entraron en el proceso, solo una pequeña fracción llegó al contacto en frío.

Por qué importaba el orden

Ejecutar todas las verificaciones en todos los dominios habría sido un desperdicio. Por ejemplo:

• el DR se podía comprobar a bajo costo y descartar pronto una gran parte;
• los análisis más costosos de grafos y del historial de tráfico solo debían ejecutarse sobre los que sobrevivían;
• enriquecer los datos de contacto no tenía sentido para un sitio que ya no había superado el filtro de calidad;
• el contacto solo debía producirse después de la calificación.

Por eso, el sistema seguía un principio simple:

Gastar progresivamente más solo a medida que aumenta la confianza.

Esa arquitectura redujo de forma considerable el gasto previsto en las API. La estimación de diseño original era de unos 1700–2200 USD al mes. El gasto real medido en las API desde el lanzamiento sumó solo 891 USD en los primeros cuatro meses.

Cada rechazo tenía que justificarse

Un resultado de aceptación/rechazo por sí solo no bastaba. La plataforma registraba:

• qué etapa tomó la decisión;
• qué verificación la activó;
• el valor medido real;
• el umbral vigente en ese momento;
• la fuente de datos;
• si una persona la corrigió.

Eso dio lugar a un registro de decisiones. Por ejemplo:

Esto resultó extremadamente valioso después. Como se conservaba el valor medido histórico, se podía cambiar un umbral y probarlo con los datos anteriores sin pagar por repetir la verificación original.

Los umbrales no eran sagrados

Los primeros valores salieron de los SOP. Los datos de producción cambiaron algunos. Por ejemplo, el umbral mínimo de tráfico inicial era de 1000. Más adelante, el sistema distinguió entre:

• umbral de evaluación;
• umbral para colocar artículos invitados;
• umbral para colocar inserciones de enlaces;
• rangos de advertencia.

Del mismo modo, la lógica original de detección de tendencias no funcionó lo bastante bien en la práctica. Podía rechazar sitios de nicho con buen rendimiento y, a la vez, pasar por alto un deterioro real. Esa lógica se sustituyó por una señal mejor, que comparaba el historial reciente de tráfico orgánico con periodos anteriores.

Es un tema importante a lo largo de todo el proyecto:

La especificación creó el modelo inicial. La evidencia de producción lo refinó.

Ingeniería de costos

Una de las partes más interesantes del sistema fue que el costo de las API se convirtió en una restricción de ingeniería medible. Cada solicitud externa registraba:

• Servicio
• Endpoint de la API
• Unidades consumidas
• Costo en dólares
• Dominio
• Fecha y hora

La plataforma acumuló cientos de miles de registros de llamadas medidas. Eso permitió identificar la lógica cara en lugar de adivinar.

Agrupar en lotes todo lo que se pueda

Ahrefs era un buen ejemplo. Una llamada para un solo dominio tenía un gran costo fijo por solicitud. Agrupar muchos dominios en una sola solicitud reducía drásticamente las unidades por dominio. Por eso, el sistema:

• agrupaba en lotes las solicitudes de DR;
• agrupaba en lotes las consultas de tráfico;
• usaba endpoints gratuitos cuando era posible;
• dejaba para el final las verificaciones de grafos costosas;
• evitaba volver a comprobar valores ya conocidos.

El modelo más barato no era en realidad el más barato

El sistema original usaba una combinación de Claude y un modelo Qwen autoalojado en GPU alquiladas. Sobre el papel, el modelo autoalojado parecía económico. En producción generó problemas operativos:

• la capacidad de GPU era irregular;
• los arranques en frío podían tardar 6–20 minutos;
• las colas podían crecer más rápido de lo que se vaciaban;
• una cola atascada tenía un tiempo de procesamiento previsto de 37 horas.

Con el tiempo, el sistema pasó a OpenRouter, con el modelo seleccionado por tarea y Claude como respaldo. El resultado fue drástico. El costo del LLM bajó de unos 89 USD en junio a 0,98 USD en septiembre, a pesar de que en septiembre se procesaron más de 10 000 llamadas al LLM.

Conseguir los datos fue más difícil que construir las pantallas

Había cuatro años de historial operativo repartidos entre varios sistemas:

• Airtable
• Exportaciones de Excel
• Pitchbox
• Cuatro buzones
• Registros de pagos

El reto no era simplemente importarlo. Los datos tenían que volverse lo bastante fiables como para que el software tomara decisiones a partir de ellos.

Reconstruir la verdad histórica

La importación dejó al descubierto varios problemas.

• Pedidos

  La primera importación de Airtable redujo miles de pedidos a 101 registros porque se había tratado como único el identificador equivocado. Hubo que reconstruirla en torno al ID real de cada registro.

• Tarifas de los editores

  Las tarifas reales negociadas con los editores no estaban almacenadas de forma estructurada en la tabla de editores. Hubo que reconstruirlas a partir de los pedidos históricos y de lo que realmente se había pagado.

• DR faltante

  Cientos de editores no tenían registrado un valor de DR válido. Esos valores se completaron a posteriori con datos actuales.

• Exportaciones contradictorias

  Una exportación de editores en Excel no era en realidad un superconjunto de Airtable. Se podían añadir desde ella los valores que faltaban, pero reemplazar en bloque los registros existentes habría destruido datos válidos.

• Buzones históricos

  Más de 71 000 correos de varios años atrás se reunieron en un único historial consultable y se asociaron a los editores por contacto, dominio, asunto e hilo.

Esta parte del proyecto reforzó otra lección:

La automatización amplifica los datos malos con la misma eficacia que los buenos.

Antes de que el sistema pudiera automatizar decisiones, había que reparar el historial existente.

Encontrar nuevos editores

Una de las mayores limitaciones del negocio antes de construir la plataforma era que la incorporación de nuevos editores casi se había detenido. La nueva plataforma añadió varios métodos de búsqueda. Entre ellos:

• Tarifas de revendedores

  Se podían importar miles de dominios de editores desde el inventario de revendedores y pasarlos por el mismo proceso de control de calidad.

• Búsqueda a partir de competidores

  La plataforma encontraba sitios con una visibilidad en buscadores similar a la de editores de calidad ya conocidos.

• Catálogos de editores

  Se podían importar en bloque y evaluar conjuntos de datos de socios.

• Extracción de resultados de búsqueda

  Los resultados de búsqueda de consultas de nicho generaban editores candidatos a un costo muy bajo.

• Listas de sitios para artículos invitados

  Las listas existentes se podían normalizar y pasar por el proceso estándar.

• Minería de backlinks

  También se probó, aunque gran parte del inventario resultante era de mala calidad.

En total, la plataforma encontró decenas de miles de dominios a través de estos canales.

La deduplicación iba antes del gasto

Un dominio que ya está en la base de datos nunca debería volver a pasar por una evaluación de pago. Parece obvio. A gran escala, sí importa.

El sistema descartó más de 2200 duplicados antes de pagar por verificaciones adicionales. Es otro pequeño ejemplo de por qué el diseño económico tenía que hacerse en la arquitectura y no a posteriori.

Contacto en frío

Solo los dominios que alcanzaban el nivel de calidad llegaban al contacto en frío. Esto invirtió el modelo operativo anterior, en el que se podía contactar con los sitios antes de haberlos calificado por completo. Ese cambio ahorró capacidad de envío y evitó dedicar recursos a editores que el negocio nunca podría usar.

El contacto se hacía desde buzones precalentados en Instantly, con varias variantes de apertura probadas en producción. Las tres variantes principales lograron tasas de respuesta de algo más del 20 %, y cada una superó al proceso manual anterior, que solía lograr tasas de respuesta de alrededor del 8–15 %.

La IA leía la respuesta. Las reglas decidían qué pasaba después.

Un LLM clasificaba las respuestas en un conjunto fijo de intenciones. Por ejemplo:

• Dio un precio
• Con interés
• Sin interés
• Fuera de la oficina
• Redirigió a otro contacto
• Aceptó la oferta
• Solo artículos invitados
• Solo inserciones de enlaces

El LLM también extraía información como el precio cotizado, la moneda y el IVA. Pero no decidía cuánto debía pagar la empresa. Eso era determinista.

Esta separación se convirtió en uno de los ejemplos más claros de la arquitectura en su conjunto:

Usar la IA para entender el mensaje. Usar código para decidir la acción de negocio.

La negociación era el SOP convertido en software

El SOP de negociación existente ya tenía:

• precios máximos por franja de DR;
• topes distintos para artículos invitados e inserciones;
• tres pasos de oferta;
• tiempos de seguimiento.

La plataforma codificó esas reglas directamente. Un flujo de negociación simplificado se veía así:

Las cotizaciones extremadamente atípicas se derivaban a una persona en lugar de seguir a ciegas la secuencia escalonada de ofertas. Por ejemplo, responder una y otra vez a una petición de 2000 USD con una contraoferta de 250 USD hacía que la automatización pareciera poco seria. Por eso, las cotizaciones muy por encima de la franja esperada se derivaban a la gerencia.

Los resultados de la negociación

De los 87 editores que entraron en la negociación automatizada, se llegó a un acuerdo con 41. Entre los editores con cotizaciones iniciales registradas, el precio de los artículos invitados bajó aproximadamente un 25 % y el de las inserciones de enlaces, aproximadamente un 20 %.

Un editor incorporado no se trataba como una transacción puntual. Su precio acordado se convertía en una tarifa reutilizable. Así, el verdadero activo no era la colocación del momento. Era una base de datos de editores cada vez mayor con condiciones comerciales conocidas.

Gestión de pedidos

Cuando llegaba el pedido de un cliente, el sistema tenía que seleccionar el editor adecuado. Eso requería tanto exclusiones estrictas como criterios de prioridad.

La plataforma generaba tres sugerencias ordenadas por prioridad para cada pedido. La gerencia podía corregir la recomendación, pero rara vez hizo falta. El motor de asignación seleccionó aproximadamente el 93 % de las colocaciones sin correcciones.

El monitoreo no terminaba cuando el enlace se publicaba

Desde septiembre, los enlaces publicados se volvían a verificar automáticamente. El sistema distinguía entre:

• Publicado
• Perdido
• Bloqueado / no verificable
• Aún sin verificar

Esta distinción importaba. Un sitio oculto tras una verificación antibots no debería clasificarse automáticamente como enlace perdido. El sistema exigía pruebas plausibles antes de marcar una colocación como desaparecida.

Eso refleja un tema más amplio de la arquitectura:

Desconocido no es lo mismo que fallido.

Portal de clientes

Los dos socios más grandes recibieron acceso a un portal de clientes de solo lectura.

Esto le dio al sistema otro papel: no solo infraestructura operativa, sino también informes para clientes.

La plataforma también se convirtió en el registro histórico

Uno de los resultados menos visibles pero importantes fue que el historial operativo dejó de estar fragmentado. El sistema consolidó:

• Pedidos
• Editores
• Tarifas
• Hilos de correo
• Pagos
• Historial de colocaciones
• Mediciones de calidad
• Estado de los enlaces
• Entregas a clientes

El historial de buzones, por sí solo, contenía más de 71 000 mensajes. Eso permitía tomar decisiones a partir del historial real de la relación con cada editor, en lugar de depender de la memoria institucional.

Los controles humanos se mantuvieron donde se movía dinero

La plataforma se diseñó para automatizar el trabajo pesado, no para eliminar la responsabilidad. Se mantuvieron dos grandes puntos de aprobación humana:

Un pedido solo se cerraba cuando el enlace estaba publicado y pagado, en cualquier orden.

De seis personas a dos

La gerencia sigue interviniendo sobre todo en pagos, aprobaciones y excepciones. La persona de operaciones gestiona el flujo en lugar de ejecutar a mano cada tarea.

La reducción de personal no era el único objetivo, pero fue una consecuencia significativa de rediseñar la operación.

Qué salió mal

La plataforma mejoró porque el uso real en producción dejó al descubierto supuestos que la especificación original no podía revelar.

1. La primera lógica de tendencia de tráfico era errónea

   El método original podía marcar sitios con buen rendimiento y, a la vez, pasar por alto un deterioro real.

   Qué cambió

   La señal se sustituyó por una comparación más robusta del historial de tráfico. Resultó a la vez más barata y más precisa.

2. El rastreador se parecía demasiado a un bot

   Los plugins de seguridad de los editores bloqueaban gran cantidad de evaluaciones.

   Qué cambió

   Las solicitudes se modificaron para comportarse de forma más similar a un navegador Chrome convencional y, con el tiempo, incluso imitar su comportamiento TLS. La tasa de lecturas correctas mejoró notablemente.

3. La IA autoalojada salía cara en lo operativo

   El modelo en sí parecía barato. La falta de capacidad de GPU, los arranques en frío y las colas, no.

   Qué cambió

   El tráfico de LLM pasó a OpenRouter, con selección de modelo por tarea. El costo por llamada cayó drásticamente y la fiabilidad operativa mejoró.

4. Las tarifas históricas no estaban donde creíamos

   La tabla de editores no contenía el historial real de tarifas negociadas.

   Qué cambió

   Las tarifas se reconstruyeron a partir de los pagos reales de pedidos históricos.

5. Leer la métrica más alta ocultaba el declive

   Usar el máximo histórico de tráfico o de DR hacía que los editores en deterioro parecieran estar en buen estado.

   Qué cambió

   Ahora el sistema lee, en cambio, la última medición válida.

6. El tráfico estimado dejaba pasar a editores débiles

   Los valores estimados no eran lo bastante fiables para decidir colocaciones.

   Qué cambió

   El sistema pasó a usar tráfico medido y a tratar lo “no medido” como pendiente de resolver en lugar de aprobarlo.

7. La negociación determinista seguía teniendo casos límite

   Una secuencia de ofertas escalonada y rígida podía comportarse mal cuando el precio inicial era extremo o explícitamente no negociable.

   Qué cambió

   • Las cotizaciones extremas se derivan a revisión humana.
   • Los precios firmes pueden aceptarse una vez agotada la secuencia de ofertas.
   • El sistema nunca hace una contraoferta por encima del precio que pide el propio editor.

8. Agrupar los correos en hilos fue más difícil de lo que parecía

   Los buzones reales contenían:

   • Redirecciones
   • Respuestas desde direcciones personales
   • Hilos antiguos
   • Respuestas automáticas de ausencia
   • Archivos adjuntos
   • Envíos duplicados

   Qué cambió

   La agrupación en hilos y la clasificación de respuestas se volvieron más explícitas, con clasificaciones guardadas, flujos de trabajo para redirecciones y protección contra envíos duplicados.

Cómo funcionaba realmente la iteración

El ciclo de producción se volvió simple:

1. Una persona del equipo detectaba un problema real.
2. El problema se investigaba utilizando datos de producción.
3. Se corregía la causa raíz.
4. Se añadía una prueba de regresión.
5. Los datos históricos afectados se reparaban de forma segura.
6. Los cambios de política de negocio se separaban de las correcciones de ingeniería.

Ese último punto importa. No todo problema de producción debe convertirse de inmediato en código. A veces el sistema funciona correctamente y lo que tiene que cambiar es la propia regla de negocio.

375 versiones en cuatro meses

La plataforma lanzó 375 versiones en sus primeros cuatro meses. Los dos primeros días dieron lugar a los cimientos, la evaluación, el contacto, la negociación, la gestión de pedidos, la consola y el programador de tareas. El resto surgió del uso en producción.

El conjunto de pruebas pasó de 112 pruebas al final del primer día a 272 después del segundo y a 1696 en la auditoría de octubre.

Resultados

La plataforma revirtió una caída de las entregas que llevaba más de un año empeorando.

En el trimestre anterior al lanzamiento, solo el 2,5 % de los pedidos se publicó en 30 días. En el primer trimestre completo tras el lanzamiento, esa cifra subió al 28,5 %, es decir, se multiplicó por más de 11.

Al mismo tiempo:

El modelo operativo también pasó de un equipo de seis personas a una persona de operaciones a tiempo completo y un gerente a tiempo parcial, con el software a cargo de la mayor parte del trabajo repetitivo.

El resultado no fue simplemente automatización. Fue una operación más fácil de medir y con menores costos fijos, capaz de ampliar la oferta disponible, procesar más oportunidades y entregar mucho más rápido que el proceso manual al que reemplazó.

Costos y herramientas

Las herramientas compartidas con otros trabajos, como Ahrefs y Claude Code, quedan fuera de ambas columnas, así que esto no es una cifra de ahorro neto.

La plataforma redujo de forma notable tanto el personal como los costos de software dedicado, a la vez que aumentaba el volumen.

Lo que aprendí

Entender el proceso antes de automatizarlo

La fase de especificación de una semana probablemente ahorró más tiempo del que costó. Los SOP existentes eran necesarios, pero insuficientes. Lo importante era entender:

• dónde había realmente criterio;
• dónde las personas solo estaban ejecutando reglas;
• dónde los datos no eran fiables;
• dónde cambiaba dinero de manos;
• dónde los errores saldrían caros.

Solo entonces se podía diseñar con inteligencia el límite de la automatización.

La economía forma parte de la arquitectura

El gasto en las API no era una partida para optimizar más adelante. Condicionaba:

• Orden de las verificaciones
• Procesamiento por lotes
• Elección de proveedores
• Almacenamiento en caché
• Deduplicación
• Elección de modelos
• Cuándo comprar datos costosos

Por eso el sistema pudo evaluar decenas de miles de dominios sin acercarse a la estimación de costos original.

Lo aprendido en producción forma parte del desarrollo

Que la lógica cambiara después no significa que la primera versión fuera un fracaso. La versión posterior fue mejor precisamente porque la primera generó evidencia. El sistema mejoró gracias a:

• Falsos positivos
• Solicitudes bloqueadas
• Respuestas extrañas de editores
• Casos límite de precios
• Registros históricos erróneos
• Comportamiento real de los usuarios del sistema

Cada problema se convirtió en una regla, una prueba o un cambio de arquitectura. Por eso la plataforma final se veía distinta de la especificación original y, aun así, conservaba sus principios centrales.

Lo que hoy construiría de otra manera

• Incorporar la observabilidad desde una etapa aún más temprana

  El registro de decisiones y la medición del uso de las API resultaron extremadamente valiosos. Los incorporaría como piezas centrales desde el primer día.

• Mantener estructurados los motivos de la revisión humana

  Cualquier corrección humana debería requerir un código de motivo fijo más un comentario opcional. Así, también es posible medir el criterio humano aplicado.

• Separar más a fondo las reglas de negocio del código

  Los umbrales, las reglas comerciales y las secuencias escalonadas de ofertas deberían trasladarse cada vez más a la configuración, en lugar de requerir nuevas versiones.

• Diseñar la agrupación de correos en hilos como un subsistema propio

  El correo parece simple hasta que se convierte en infraestructura operativa. La identidad de los hilos, las redirecciones, los rebotes, los avisos de ausencia, los adjuntos y la protección contra duplicados merecen un modelado explícito.

• Hacer que la búsqueda sea continua

  El siguiente paso lógico es convertir la búsqueda, una actividad que se inicia a mano, en un motor continuo de incorporación de nuevos editores, impulsado por listas semilla guardadas y por la capacidad disponible.

Tecnologías utilizadas