Del scraping al Micro-SaaS: convierte páginas en alertas B2B que merecen atención
Diseña un monitor de cambios en API con Firecrawl, evidencias, fechas y validación, y convierte la recopilación de páginas en una oportunidad B2B.
Las voces dependen del navegador y del dispositivo; algunas necesitan conexión a internet. Los bloques de código no se leen en voz alta.
Lectura estimada: 10 minutos. Referencias consultadas el 26 de octubre de 2026.
Imagina recibir un aviso útil cada vez que cambie la documentación de una API: qué campo se modificó, cuándo entra en vigor, qué integraciones conviene revisar y dónde está la evidencia original. Para quien mantiene sistemas conectados a marketplaces, eso puede valer mucho más que otro panel lleno de gráficos.
La idea empieza recopilando páginas, pero el producto aparece cuando esa recopilación permite tomar una decisión fiable. Ahí veo espacio para Micro-SaaS B2B: elegir una rutina importante de un sector y reducir el esfuerzo necesario para seguirla.
Mi experiencia con integraciones en Oombe acerca este problema a la realidad. La documentación puede cambiar mientras el negocio sigue funcionando. Sin embargo, el sistema que propongo aquí es un ejemplo de arquitectura y oportunidad de producto, no la descripción de una funcionalidad ya implementada en Oombe.
El cliente quiere saber qué merece su atención
“Transformo páginas en Markdown” describe una capacidad técnica. “Te aviso cuando un cambio relevante puede afectar a tu integración, con fuente y evidencia” describe un resultado que alguien puede evaluar.
Antes de elegir una herramienta, definiría tres cosas: quién recibirá el aviso, qué decisión tomará y cuánto cuesta descubrir ese cambio demasiado tarde. Eso ayuda a escoger un alcance suficientemente pequeño para aportar valor y medir la calidad.
Para este artículo, imaginemos un equipo que sigue documentación y comunicados oficiales de algunas API de marketplaces. El monitor observa fuentes, registra versiones, detecta cambios y prepara una revisión. El equipo responsable sigue decidiendo si debe modificar una integración.
Dónde encaja Firecrawl
La documentación de Scrape presenta la conversión de páginas en Markdown, HTML y datos estructurados, incluido contenido renderizado con JavaScript. Es un componente para obtener contenido.
El modo JSON permite solicitar campos de una página mediante un esquema. La página de Extract presenta /agent como sucesor para extracción con descubrimiento más amplio. La elección debe ajustarse a la tarea y a la versión de API utilizada.
Yo empezaría con una lista conocida de fuentes. Un agente explorando la web puede ayudar después, pero amplía el espacio de búsqueda y las preguntas sobre relevancia. Un conjunto delimitado facilita explicar por qué cierta información entró en el producto.
Cada registro necesita conservar su origen
El corazón del monitor sería un registro que preserve lo observado. Esta es una propuesta de modelo para el producto, no una respuesta nativa de Firecrawl:
| Campo | Función en el producto |
|---|---|
source_url |
Dirección de la página original |
observed_at |
Momento en que el monitor recopiló la información |
published_at |
Fecha de publicación identificada, o null |
effective_at |
Fecha de vigencia expresada en la fuente, o null |
content_hash |
Identificador calculado sobre el contenido normalizado |
evidence |
Fragmento que respalda cada afirmación extraída |
change_type |
Clasificación propuesta: campo, plazo, autenticación u otra |
review_status |
Estado de la validación humana o automática |
Separaría los datos observados de las interpretaciones. “El texto ahora menciona el campo X” puede demostrarse comparando versiones. “Todos los clientes se verán afectados” requiere otro análisis, posiblemente con conocimiento de las integraciones existentes.
También permitiría valores ausentes. Un null honesto es más útil que una fecha inventada para completar el JSON. La base de datos debe representar incertidumbre sin obligar al modelo a rellenar los huecos con creatividad.
Un pipeline pequeño, pero completo
El flujo empezaría con un catálogo de fuentes: URL, responsable interno, asunto y frecuencia adecuada. La recopilación entraría en una cola con límites de concurrencia y tratamiento de fallos. Un error temporal no debería convertirse en “la documentación ha sido eliminada”.
Después normalizaría el contenido relevante, conservando una versión suficiente para revisarlo. Menús, banners y elementos que varían sin cambiar la información necesitan un tratamiento cuidadoso para no fabricar novedades en cada ejecución.
El hash permitiría detectar igualdad en el contenido normalizado. Si no cambió nada, la tarea terminaría sin otra interpretación de IA. Si hubo cambios, el sistema compararía versiones y enviaría únicamente el material necesario para extraer información.
Un validador comprobaría campos, fechas y presencia de evidencias. Después, las reglas del producto decidirían entre archivar, pedir revisión o preparar una alerta. Un identificador del cambio evitaría que un reintento enviara otra vez la misma notificación.
Conceptualmente: recopilar, normalizar, comparar, extraer, validar y entregar. Cada etapa debe hacer visible cuándo falla. De lo contrario, “sin novedades” podría significar estabilidad o un recolector averiado desde hace tres días.
El contenido recopilado debe entrar como dato que analizar. Una instrucción encontrada en una página no debería obtener permiso para ejecutar herramientas, modificar reglas o enviar información a otro destino. Mantendría esos permisos fuera de la interpretación y trataría su resultado como una propuesta que requiere validación.
Utilizar un LLM tampoco elimina el mantenimiento: algunos problemas de selección de elementos pueden dar paso a errores de interpretación. Debemos observar ambos.
Detectar un cambio no basta para comprender su impacto
Change Tracking de Firecrawl compara recopilaciones y ofrece diferencias de contenido o campos. La documentación indica que los snapshots persisten y no caducan. Ese almacenamiento debe formar parte de la decisión de retención del proyecto.
En nuestro monitor, una diferencia iniciaría el análisis. Cambiar una frase explicativa puede ser irrelevante; modificar un requisito de autenticación puede merecer atención. Crearía categorías sencillas y evaluaría errores antes de automatizar clasificaciones más delicadas.
La alerta útil incluiría fuente, fragmento anterior, fragmento nuevo, fecha observada y una explicación breve de la posible consecuencia. Cuando el impacto dependa de información que el monitor no tiene, debería indicarlo.
Por ejemplo: “La fuente ahora exige este campo. Revisa los flujos que envían esa operación”. Es más responsable que anunciar que todo el sistema dejará de funcionar sin conocer a sus consumidores.
Las fechas merecen un tratamiento específico
Un monitor regional de noticias enfrenta una trampa parecida. Encontrar hoy una página sobre un evento no significa que vaya a celebrarse este año. Una URL antigua puede seguir accesible, reaparecer en búsquedas o recibir un cambio de diseño.
Mantendría separadas tres fechas: recopilación, publicación y acontecimiento. Para una API, añadiría la vigencia cuando exista un anuncio explícito. Ninguna debería rellenarse automáticamente con otra por comodidad.
Si el texto solo dice “este viernes”, puede faltar contexto para determinar una fecha absoluta. El sistema puede solicitar revisión, buscar elementos adicionales en la propia fuente o dejar el campo vacío. Publicar una certeza fabricada es un fallo de producto, aunque el resumen esté muy bien escrito.
Esa disciplina también ayuda a deduplicar. Actualizar el mismo comunicado puede justificar una nueva versión; republicarlo sin cambios quizá no merezca otro aviso. Necesitamos representar la identidad del acontecimiento, además de la identidad de la página.
Un JSON válido todavía tiene que ser correcto
Un esquema organiza la salida, pero el producto necesita comprobar si los valores corresponden a la evidencia. Evaluaría por separado identificadores, unidades, fechas, campos ausentes y elementos repetidos.
ExtractBench reúne 35 PDF y 12.867 campos evaluables para estudiar extracción estructurada. Es un benchmark de documentos, no una tasa universal de precisión para scraping web. Respalda la necesidad de evaluaciones específicas, sin justificar extrapolar sus cifras a este monitor.
En el experimento propuesto, el equipo anotaría ejemplos: cambios importantes, modificaciones cosméticas, páginas indisponibles y comunicados antiguos. Mediríamos campos correctos, alertas relevantes, falsas alertas y cambios no detectados.
Para mí, el indicador decisivo sería la utilidad de la notificación. Si el usuario debe leer diez avisos irrelevantes para encontrar uno importante, la herramienta está trasladando trabajo, aunque produzca un porcentaje excelente de JSON bien formado.
El mismo enfoque ayuda al enriquecimiento B2B
Una aplicación posible para un proyecto como CNPJ.space sería enriquecer registros empresariales con evidencias de presencia digital. La propuesta exige cuidado con el lenguaje y con la asociación entre entidades.
“No se encontró un sitio web en las fuentes consultadas” es una observación limitada. “La empresa no tiene sitio web” es una conclusión mucho más amplia. Conservaría la primera, junto con fecha, método y fuentes, hasta tener evidencia suficiente para afirmar otra cosa.
Razones sociales parecidas, marcas comerciales, sucursales y dominios antiguos pueden hacer ambigua la asociación. El flujo debería admitir candidatos y revisión, en lugar de vincular el primer dominio encontrado al registro empresarial.
El posible valor comercial está en reducir investigación manual y organizar evidencias. Convertir el resultado en prospección implica otras decisiones sobre relaciones y tratamiento de datos; la recopilación no resuelve toda la operación.
Los costes y el precio empiezan en el diseño
Calcularía el coste por fuente monitorizada y por alerta aceptada. Incluiría recopilación, interpretación, almacenamiento, operación y revisión. También mediría el trabajo ahorrado al cliente mediante un método explícito, sin asumir que cada página leída equivale a minutos ahorrados.
Una frecuencia única para todas las fuentes desaprovecha oportunidades. Una página de referencia puede cambiar poco; un canal de comunicados puede necesitar seguimiento más frecuente. El producto puede ofrecer frecuencia y cobertura proporcionales a la necesidad.
Para cobrar, veo opciones como número de fuentes, equipos atendidos y nivel de revisión. Evitaría vender “monitorización ilimitada” antes de comprender comportamiento, coste y soporte. La promesa comercial debe encajar en la capacidad que realmente podemos operar.
También definiría una política de recopilación: priorizar API o feeds oficiales cuando cubran la necesidad, respetar permisos y controles de acceso y limitar el alcance. Eso organiza el servicio y evita convertir cada nueva fuente en una aventura improvisada.
Documentos y páginas son entradas diferentes
anydoc es un conversor de documentos escrito en Rust. El OCR alojado es opcional y, cuando se utiliza para un documento que lo necesita, envía el archivo entero al servicio. Por tanto, hablar de “conversión local” exige comprobar la ruta efectiva de procesamiento.
En el diseño del producto, clasificaría la entrada antes de elegir el procesamiento. Una página pública, un PDF digital y un documento interno escaneado pueden requerir tratamientos distintos. Así evitamos aplicar el mismo mecanismo a todo por simple comodidad.
Un primer producto que pueda evaluarse
Empezaría con pocas fuentes oficiales, un solo tipo de alerta y un equipo piloto. Antes de ampliar, observaría un periodo de uso: qué avisos fueron útiles, cuáles llegaron tarde, cuáles generaron trabajo y cuáles faltaron.
Después ajustaría recopilación, normalización y criterios de relevancia. Solo entonces añadiría fuentes o descubrimiento automático. El propósito de la primera versión sería demostrar que el monitor merece un lugar en la rutina de alguien.
Esa es la conexión con automatizar trabajo administrativo repetitivo: reunir información dispersa, comprobar su origen y reducir el esfuerzo de seguimiento puede aportar mucho valor.
El scraping abre la puerta. Un Micro-SaaS sostenible necesita entregar información rastreable, en el momento adecuado y con un nivel de confianza que el cliente comprenda. Aplicar ese cuidado a un problema concreto es lo que convierte una recopilación interesante en algo por lo que tiene sentido pagar.
